Python developers are embracing type hints
191–200 of 581 posts
Re: Python developers are embracing type hints
#192Type hints in Python add a great amount of visual noise to the code, and I actively avoid them wherever possible. If static typing is a must, use a language where static typing is not an afterthought, and let Python be Python.
I guess one man's noise is another man's treasure :P
Re: Python developers are embracing type hints
#193Earlier quoted context omitted.
It's claims like that which used to put me off embracing type hints! I'd been programming for 20+ years and I genuinely couldn't think of any situations where I'd had a non-trivial bug that I could have avoided if I'd had a type checker - claims like "reduce dev time by 50%" didn't feel credible to me, so I stuck with my previous development habits. Those habits involved a lot of work performed interactively first -…
It depends on the project. If you're working always on one project and you have all the time in the world to learn it (or maybe you wrote it), then you can get away with dynamic types. It's still worse but possible. But if you aren't familiar with a project then dynamic typing makes it an order of magnitude harder to navigate and understand. I tried to contribute some features to a couple of big projects - VSCode and…
Flip side of this is that I hate trying to read code written by teams relying heavily on such features, since typically zero time was spent on neatly organizing the code and naming things to make it actually readable (from top to bottom) or grep-able. Things are randomly spread out in tiny files over countless directories and it's a maze you stumble around just clicking identifiers to jump somewhere. Where something is rarely matter as the IDE will find it. I never develop any kind of mental image of that style of code and it completely rules out casually browsing the code using simpler tools.
Re: Python developers are embracing type hints
#194Earlier quoted context omitted.
People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exceptio…
Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned . And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has…
Even within a recent toy 1h python interview question having types would've saved me some issues and caught an error that wasn't obvious. Probably would've saved 10m in the interview.
Re: Python developers are embracing type hints
#195But they both seem to handle typing similarly.
I can't put my finger on why. Anybody else?
Re: Python developers are embracing type hints
#196My view on typing in Python (a language I have used for decades) is that if I wanted types I would use a language designed from the ground up with strong and consistent typing built-in. Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis. I use plenty of statically typed languages, Python's type hinting does not bring me joy.
Can you help me out with an example of a Python usage pattern against which the type system seems to be fighting?
Re: Python developers are embracing type hints
#197As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.
> all the popular dynamic languages have slowly become statically typed I’ve heard this before, but it’s not really true. Yes, maybe the majority of JavaScript code is now statically-typed, via Typescript. Some percentage of Python code is (I don’t know the numbers). But that’s about it. Very few people are using static typing in Ruby, Lua, Clojure, Julia, etc.
For the average Julia package I would guess, that most types are statically known at compile time, because dynamic dispatch is detrimental for performance. I consider, that to be the definition of static typing.
That said, Julia functions seldomly use concrete types and are generic by default. So the function signatures often look similar to untyped Python, but in my opinion this is something entirely different.
Re: Python developers are embracing type hints
#198Python with type hints still lacks the performance benefits of static typing in a compiled language setting?
Re: Python developers are embracing type hints
#199I'm always surprised when people suggest using a different language if you want typing in Python. Python's (second?) largest appeal is probably its extensive ecosystem. Whenever people suggest just changing languages, I wonder if they work in isolation, without the need for certain packages or co-worker proficiency in that language.
Re: Python developers are embracing type hints
#200I'm always surprised when people suggest using a different language if you want typing in Python. Python's (second?) largest appeal is probably its extensive ecosystem. Whenever people suggest just changing languages, I wonder if they work in isolation, without the need for certain packages or co-worker proficiency in that language.
And it happens quite often in large codebases. Sometimes external dependencies report wrong types, e.g., a tuple instead of a list. It's easy to make such a mistake when a library is written in a compiled language and just provides stubs for types. Tuples and lists share the same methods, so it will work fine for a lot of use cases. And since your type checker will force you to use a tuple instead of a list, you will never know that it's actually a list that can be modified unless you disable type checking and inspect the data.