I inherited a python based build system which had been written without any unit tests because....it's a build system right? right?? Anyhow it was the kind of thing where you'd build for 20 minutes (Android) and then have some kind of trivial error in the python code at the end of the build. You fix that and run again and waste another 20 minutes on the next thing. I couldn't do unit tests all at once because of the d…
The different uses of Python type hints
51–60 of 70 posts
Re: The different uses of Python type hints
#52For a bit of a quantitative analysis on this, we had fun doing surveying programmers here, see Table 7 @ https://lmeyerov.github.io/projects/socioplt/papers/oopsla20... Ex: Programmers value types much more for documentation vs preventing bugs. I had not expected that answer!
That number seems to be from 2013. I imagine it would be much higher today - 10 years ago dynamic typing was at the peak of its hype cycle, and right now it seems to be in the Trough of Disillusionment.
Re: The different uses of Python type hints
#53Earlier quoted context omitted.
With python you can have your cake and it eat it, though. Mock up something fast, no type hints. Now, take that POC and make it production ready, by using mypy and pydantic.
But why does it need additional dependencies just to get all language features?
(This is also why there is no good HTTP client library in the stdlib, even though the popular `requests` library gets new releases every 6 months with minor fixes only)
Re: The different uses of Python type hints
#54I inherited a python based build system which had been written without any unit tests because....it's a build system right? right?? Anyhow it was the kind of thing where you'd build for 20 minutes (Android) and then have some kind of trivial error in the python code at the end of the build. You fix that and run again and waste another 20 minutes on the next thing. I couldn't do unit tests all at once because of the d…
IMO type hints are mostyl about (significantly!) improving readability.
Re: The different uses of Python type hints
#55Earlier quoted context omitted.
> Both mypy and pyright will do that. This still makes me seethe. We have pip, poetry, conda, and more. The Python folks knew that multiple incompatible systems would arise from a grammar spec without a behavior spec. And here we are. Python doesn't do anything useful with the types, but third-parties are left to their own devices.
> The Python folks knew that multiple incompatible systems would arise from a grammar spec without a behavior spec. Python typecheckers predate in-language annotations and drove the spec, not vice versa.
[0] https://peps.python.org/pep-3107/
[1] https://github.com/python/mypy/commit/6f0826a9c169c4f05bb893...
[2] https://peps.python.org/pep-0484/
[3] https://github.com/microsoft/pyright/commit/1d91744b1f268fd0...
Re: The different uses of Python type hints
#56Not to start a religious war, but I think Ruby screwed-up on gradual typing making it too complex and too many steps. Attempting to maintain perfect Microsoft-legacy-style compatibility rather than have a hard change is the greater failure than having a truly new major version rather than arbitrary marketing increments. Crystal is compiled with static typing but looks like Ruby. The type specification it uses emulate…
Re: The different uses of Python type hints
#57Earlier quoted context omitted.
> The way everybody else seems to be going is strong typing at function interfaces, with automatic inference of as much else as can be done easily Both mypy and pyright will do that. If your function return type is annotated, they will infer the type of the receiving variable. If you have two branches where a variable can receive two types, pyright will infer the union type. Similar for None. Example: a = input() if…
> Both mypy and pyright will do that. This still makes me seethe. We have pip, poetry, conda, and more. The Python folks knew that multiple incompatible systems would arise from a grammar spec without a behavior spec. And here we are. Python doesn't do anything useful with the types, but third-parties are left to their own devices.
That said, I don't think this a reason not to use type hints. They're still useful (see TFA), even if they're not perfect.
Re: The different uses of Python type hints
#58For a bit of a quantitative analysis on this, we had fun doing surveying programmers here, see Table 7 @ https://lmeyerov.github.io/projects/socioplt/papers/oopsla20... Ex: Programmers value types much more for documentation vs preventing bugs. I had not expected that answer!
They never appreciate that type hints make code easier to read and write and navigate and understand and maintain.
Often it's Vim users that have never used a good IDE.
Re: The different uses of Python type hints
#59Not to start a religious war, but I think Ruby screwed-up on gradual typing making it too complex and too many steps. Attempting to maintain perfect Microsoft-legacy-style compatibility rather than have a hard change is the greater failure than having a truly new major version rather than arbitrary marketing increments. Crystal is compiled with static typing but looks like Ruby. The type specification it uses emulate…
How does Ruby’s system look? Python’s type hints are fully optional and opt-in, typed and non-typed code works the same (even though type checkers may complain about the latter).
The two languages take such different approaches because their designers have different feelings about static typing. Guido and the Steering Council seem to want Python to be as statically-typed as possible, whereas Matz thinks "static type declaration is redundant" [0].
Re: The different uses of Python type hints
#60For a bit of a quantitative analysis on this, we had fun doing surveying programmers here, see Table 7 @ https://lmeyerov.github.io/projects/socioplt/papers/oopsla20... Ex: Programmers value types much more for documentation vs preventing bugs. I had not expected that answer!
> I enjoy using static types: 18% (+/- 8) That number seems to be from 2013. I imagine it would be much higher today - 10 years ago dynamic typing was at the peak of its hype cycle, and right now it seems to be in the Trough of Disillusionment.
Speaking as a scientist, I'd love to see a round 2 of this work to see how much things are the same vs different. The premise for the work was doing more serious sociological methods could help understand tough phenomena here & suggest new solutions, so bringing in longitudinal analyses would be fascinating.
FWIW, if I remember right:
- Languages like Java, C++, .NET were the most popular. Maybe iOS/Android apps too?
- Buzz around then were Scala + Java (big data), Haskell, Elm, D, and the beginnings of Rust.
- TypeScript was already a year or two in as well. But population-wise, probably still niche.
- That was probably also some of the heaviest Node
Nowadays, we also see heavy rises in dynamic languages:
- Professional data scientists using Python & R. I think Python has become the #1 language for new folks?
- Go looks like a statically typed language... until you compare it to modern C++, D, Rust, etc
So I wouldn't be surprised to see a shift.. but then again, not at all obvious how much, and especially controlling for selection bias..