Love this framing of #Python as two languages that are immediately interoperable. Similar benefits to the TS/JS split but you can write one in the other without compiling down.

threeofwands.com/python-is-two

@sethmlarson @hynek this is giving mypy’s various gradations of escape hatches too little credit. Typing can be quite extensive internally to “infrastructure” code, and a great deal of “this must be untyped, it’s too dynamic” is either apologia for antiquated design or a misunderstanding of the tools available. I gave a talk at pybay this year about this exact problem.

@sethmlarson @hynek I do agree with the broad strokes here but I think it has the main thrust of the 2-languages benefit backwards: untyped is good for *quick scripts*, code that you experiment with and throw away or has to work with semi structured or unknown data. Typed code takes more effort to produce, and while the cost/benefit on that is usually very good, the ability to discard it and YOLO your way to a prototype in the first few pages of code on a project eliminates critical friction.

Follow

@glyph @sethmlarson @hynek Weird, I feel like I get the greatest bang for my buck when using at least basic typing on YOLO scripts because I’m never going to unit test them.

For anything serious, I’m writing extensive unit tests, and the type checking stuff is less likely to find bugs that, say, hypothesis wouldn’t.

@glyph @sethmlarson @hynek In fact, for more serious stuff, I find that type checking is way more likely to put me in a situation where I’m pointlessly fighting with the type checker and reporting bugs to mypy because I can’t express the contract of the function easily using the type system.

For quick scripts I’m usually just moving around strings or ints or paths or something and I’m not nearly as likely to write something like a function that takes functions and returns classes constrained to look a very specific way, or something with some cyclic references or something.

@glyph @sethmlarson @hynek Of course I still use type hints in big projects because they’re useful for other people, or for when I start to build on top of them.

So I guess I’m one of those people who thinks type checking is useful for all kinds of code.

@pganssle @sethmlarson @hynek I feel like those situations break down into 4 general classes for me, in decreasing order of frequency:

1. my type-mangling design is too complex, and I take a design cue; "easier for mypy type" often means "easier for humans"
2. The design is good but I need combine higher-order stuff like type alias bounds, protocols, etc, in a novel way
3. The design is good but requires one specific type:ignore
4. There's a mypy bug or limitation that needs to be fixed

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.