Live data from Hacker News

The different uses of Python type hints

lukeplant.me.uk

51–60 of 70 posts

Re: The different uses of Python type hints

#51
post #46

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…

IMO type hints are mostyl about (significantly!) improving readability.

Re: The different uses of Python type hints

#52

For 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.

Re: The different uses of Python type hints

#53
post #28

Earlier 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?

The Python community dislikes putting fast-changing things in the stdlib, because being in the stdlib slows down the development, and ties any improvements to upgrading Python.

(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

#54
post #46

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…

IMO type hints are mostyl about (significantly!) improving readability.

Also about improving editor experience and having better auto-completion that's based on type hints.

Re: The different uses of Python type hints

#55
post #15

Earlier 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.

Function annotations were added as part of Python 3.0, with PEP 3107, proposed in 2006 [0]. The first public mypy commit was in 2012 [1], and originally it was using C++-style syntax (`list lex(str s):`). The `typing` module and the official use of function annotation for type hints came in 2014 with PEP 484 [2], inspired by mypy. The first pyright commit was in 2019 (with a lot of code in the third commit [3], possibly moved from the VSCode extension).

[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

#56

Not 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).

Re: The different uses of Python type hints

#57
post #15
post #8

Earlier 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.

I agree. I believe the type checker should've been part of the interpreter, or a module like pip. Differences between mypy and pyright drive me crazy.

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

#58

For 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!

Yeah I've found when trying (and failing mostly) to convince Python developers to use type hints that they often think it's only to fix bugs and then resist because a) of course their code doesn't have bugs, and b) they've already written their code and discovered lots of bugs painfully at runtime, so they wouldn't get most of the bug-finding benefits anyway.

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

#59

Not 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).

I believe the Ruby designers have refused to add syntax for type hints, so they need to either be in comments on separate lines from the code itself or even in a separate file. They are therefore less ergonomic to use - but the increased separation from the code means that they are mostly used purely as (machine-verifiable) comments. On the other hand Python's type hints tend to be deeply intertwined with the code, and are even required to access new language features such as dataclasses.

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].

[0] https://evrone.com/yukihiro-matsumoto-interview

Re: The different uses of Python type hints

#60
post #52

For 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.

That's a legit hypothesis!

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..

Post reply on HN