Important to realize glyph's twitter followers are not representative of all Python users.
In general, people who follow him are going to be more "into" Python than someone who just uses it to get their job done, and thus more likely to use optional tooling with a large overhead like mypy.
That will skew the results in favor of mypy in this poll. Though the poll getting on the HN front page will balance that somewhat.
I'm just using it to get my job done, and really couldn't imagine working with Python without it.
I'd consider static type checker as optional if you are playing around with small or throwaway scripts, but for any half serious project, it should be a requirement.
IME I don't consider it slow, and it's definitely not visibly slower than pylint, flake8, or similar tools for other languages.
Dropbox, which has one of the biggest Python codebases, uses it, and most mypy maintainers including Guido work there.
Yea, it may slightly slow down the initial draft due to needing to type a little bit more, but it helps speed up maintainability and readability a ton and it helps eliminate a bunch of bugs so I think it has definitely increased productivity in my experience.
The biggest problem with mypy is that it's written in python. It's slow. It needs to be rewritten in rust or go to make it faster like how js ecosystem is moving in that direction. All the tooling is moved to faster compiled languages.
I see a lot of sort of 'programming culture' for given languages, practices, even discussion of working conditions and etc that on social media are taken as standard operating procedure. Highly active and even highly knowledgeable folks seem to portray various practices and etc are a given ... that I suspect are actually outliers.
One of the first things you learn in theoretical sampling classes is that polls where people self select to participate (like twitter polls) are garbage
The results are good, they are just, "of the population that uses twitter" ...
What I would really be interested in, is do library developers use or intend to use mypy? Because if your libs are typed checked and your APIs are well constructed, a lot of that safety will flow to the clients.
Maybe those 40% would love to use it if something was changed or fixed. I think these numbers are frankly amazing, a year from now we reach an inflection point where mypy is used by the majority of some segment of the Python developer ecosystem.
I run a fairly large open source project (https://github.com/facebookresearch/ParlAI/) and we use mypy. Our experience has been that it can be quite difficult to placate, so we usually treat it only as a warning. However, having our code annotated with types in many places has significantly improved developer productivity, just from having less ambiguity with what you're dealing with.
When I read the twitter replies, it doesn't make me optimistic for the future of typed python. I don't work with Python often, so I don't know what the "truth on the ground" is, but it seems like having a language divided between several different type-checking implementations is going to be a nightmare for things like interoperability of frameworks.
I'm imagining a future 5 years down the road where some poor python developer has to use some "polyfill" solution because they want to import a library which was developed with a type-checking solution which is no longer main-stream, or because the type-checkin solution they're using has breaking changes with respect to previous versions.
Python 3 type annotations are part of the language spec. Whether you use mypy or a different library for type checking shouldn’t necessarily make a difference to the code.
Type annotations may be part of the language spec, but the way they are enforced is not. Different type checking libraries have made different design choices (leniency vs strictness, type inference vs gradual typing etc.). Although these differences don't matter at runtime, they do mean that code which passes one particular type checker might fail with another.
There is no semantic meaning given to type annotations by the interpreter. There's no need for polyfill nor are there issues with interoperability of frameworks because, again, type annotations have no semantic meaning.
They're like comments, they're only there for developer convenience and can be completely ignored.
The ecosystem is already pretty split on several fronts, not just typing. Python 2 vs 3, async vs blocking, packaging tools, etc.
I left python 3 or 4 years ago and not planning to go back (basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects).
The language is nice, and frameworks such as Django are great, but the mess the ecosystem has become is not something I miss.
* pip is the most popular in the industry, conda serves a different purpose if your focus is mainly on scientific computing
* what does async vs blocking even mean in this context? all languages have the same problem, just use the libraries that are non-blocking.
* mypy is the static type checker that is the most popular (28.3k repositories, 1.9k packages), if you are using other type checkers then congrats, you will just be the CoffeeScript/Reason user of the JS world, refusing to believe that TypeScript won the mindshare
I agree that the ecosystem is a bit messy, but it's more of a function of how long Python has been around, and how successful it has been. Newer languages have the benefit of hindsight.
Take `go fmt` or `cargo fmt`. black is the de facto autoformatter, but it's still an optional dependency. Maybe like virtualenv it'll eventually be integrated into the standard library/distro. That would help. With other stuff, the split you describe could be a real problem, although for the majority of Python users, using mypy and poetry is fine.
> basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects
If you're actually serious, this is intriguing to me. Business-wise, I have never seen the math shake out this way. When we've done sizings/estimated developer hours and ROI, it's always been more economic to slowly migrate to Python 3 vs a rewrite, even if the dev team is also already using and well-versed in another language. If you're able to provide more details, please do. It's so rare to have a high-quality discussion about this.
This isn't an issue in 2021. Python 2 reached its EOL over a year ago, and those who own old Python codebases have had known for literally almost 13 years now that Python 2 would be EOL'd when Python 3 came out in 2008.
This seems very positive to me - specifically that a sizeable population recognise they really don't need it.
Used correctly - i.e. you’re leaning on structural typing, so you invest your time in Protocols that go “quack” rather than hard-to-test, brittle, nominatively typed Ducks who quack - which incidentally is exactly the path the mypy getting started docs seems to focus on, why?! - that’s just setting people up for failure, i digress.
Mypy, pyright etc are fantastic tools in the toolbox, sure to save time but Cargo culting is a pain to deal with. See for example 2 decades of empty getters / setters in Java “in case we ever want to add some behaviour in future”.
Gradual typing of the structural variety is fantastic, you’ll know if you’re doing it right because you’ll spend surprisingly little time thinking about types, you won’t spend any time wrestling with mypy to convince it of your idea and when it does complain your reaction will be a legitimate “aha, yeah ok fair shout, you got me” not “oh ffs!” :-)
One really cool thing about gradual typing - if you get it wrong and i have to take over your code, i can at least turn it off. One of the reasons i love tests so much - I don’t have to accept yours if they’re a bear to maintain, i can easily bring along my own instead.
I find it hard to imagine cases where gradual typing would have any advantages over a language with decent, modern type inference. In the latter case, you're still not typing type specifiers very often, but you get unambiguous function signatures, and can eliminate whole classes of runtime errors.
Data science. Static typing is a complete PITA when you're doing exploratory data work. Type inference only fixes things on a superficial level.
For data engineering, I haven't had a chance to try this due to lack of language options, but I strongly suspect that structural typing would be much more useful than nominal typing.
Dynamic types are considerably more flexible than static types. It's not just about typings them out. There are lots of types that you just can't have in static languages (that exist so far), because the language doesn't have the vocabulary to describe them.
Code in dynamic languages typically takes advantage of the flexibility to do meta-programming, which can significantly both the amount of code required to complete a task and its complexity.
What seems positive to me is that there's a good mix. It speaks to the eminent pragmatism of the way Python decided to handle typing and type hints.
I've found that there is no one best typing discipline. Different approaches work better for different problem domains. And I'm currently using Python in so many different problem domains that I find it convenient that Python now allows me to choose the best typing discipline for the job.
It's true that this means that Python isn't the best at any particular way of doing typing. But that also seems appropriate. Being a jack of all trades and master of none is sort of Python's thing nowadays.
TBH once you start using a fair number of dependencies (say, your average Flask or Django app) you end up with so many workarounds and flags like ignore_missing_imports that the benefit of mypy is marginal compared with other tools like flake and unit tests. I tend to use it more with libraries and less with applications.
In my experience it’s been worth the trouble of writing partial type stubs for your project’s dependencies.
And by partial I mean only typing the stuff you end up using, so if you just use one function from some huge, untyped package, just type that one part for now.
The way I see it, you write the stub once, and then the API has less ambiguity and you get type checking.
Not to mention the performance. Perhaps it's improved since, but just a year ago it took an upwards of 10-20 seconds to type check a trivial repository.
That seems totally reasonable. Progressive type safety is one of the major wins of Python IMO. I don't need type annotations to write some codemod script, certainly do to write a robust web service.
Good progress. I think you'd be mad to not use type hints, even for small scripts they're hugely advantageous. It's especially nice now that VSCode supports them well.
The only problems I have with them are that they are completely ignored by Python itself - you have to run a separate type checker. That's a fairly stone-aged system. And also I with VSCode had something like Typescript's "no implicit any" so it was more obvious where you had to put types that couldn't be inferred.
I personally hate typing in Python. Python now feels like Typescript, and when using pyright, you actually get something that looks very much like type file for JS when you step into library code, instead of library source code itself.
Honestly, I don't like the direction Python is taking lately. It used to be easy, approachable, dynamically typed, strongly typed language. Now, syntax is getting polluted and there are definitely more than 2 ways of doing things.
Typescript at least has the excuse that you have to run JS, so the approach is more sensible. With types in Python, for the most part, you could choose a different language.
Readit News
In general, people who follow him are going to be more "into" Python than someone who just uses it to get their job done, and thus more likely to use optional tooling with a large overhead like mypy.
That will skew the results in favor of mypy in this poll. Though the poll getting on the HN front page will balance that somewhat.
I'd consider static type checker as optional if you are playing around with small or throwaway scripts, but for any half serious project, it should be a requirement.
IME I don't consider it slow, and it's definitely not visibly slower than pylint, flake8, or similar tools for other languages.
Dropbox, which has one of the biggest Python codebases, uses it, and most mypy maintainers including Guido work there.
Guido hasn't worked at Dropbox since 2019. He retired for a bit, but is now in the Developer Division at Microsoft.
I see a lot of sort of 'programming culture' for given languages, practices, even discussion of working conditions and etc that on social media are taken as standard operating procedure. Highly active and even highly knowledgeable folks seem to portray various practices and etc are a given ... that I suspect are actually outliers.
What I would really be interested in, is do library developers use or intend to use mypy? Because if your libs are typed checked and your APIs are well constructed, a lot of that safety will flow to the clients.
Maybe those 40% would love to use it if something was changed or fixed. I think these numbers are frankly amazing, a year from now we reach an inflection point where mypy is used by the majority of some segment of the Python developer ecosystem.
I'm imagining a future 5 years down the road where some poor python developer has to use some "polyfill" solution because they want to import a library which was developed with a type-checking solution which is no longer main-stream, or because the type-checkin solution they're using has breaking changes with respect to previous versions.
They're like comments, they're only there for developer convenience and can be completely ignored.
I left python 3 or 4 years ago and not planning to go back (basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects).
The language is nice, and frameworks such as Django are great, but the mess the ecosystem has become is not something I miss.
* Python 2 is dead.
* pip is the most popular in the industry, conda serves a different purpose if your focus is mainly on scientific computing
* what does async vs blocking even mean in this context? all languages have the same problem, just use the libraries that are non-blocking.
* mypy is the static type checker that is the most popular (28.3k repositories, 1.9k packages), if you are using other type checkers then congrats, you will just be the CoffeeScript/Reason user of the JS world, refusing to believe that TypeScript won the mindshare
Take `go fmt` or `cargo fmt`. black is the de facto autoformatter, but it's still an optional dependency. Maybe like virtualenv it'll eventually be integrated into the standard library/distro. That would help. With other stuff, the split you describe could be a real problem, although for the majority of Python users, using mypy and poetry is fine.
> basically the company I was working for mandated they were not going to ever upgrade to python 3 because of the effort required and thus stopped all migration related projects
If you're actually serious, this is intriguing to me. Business-wise, I have never seen the math shake out this way. When we've done sizings/estimated developer hours and ROI, it's always been more economic to slowly migrate to Python 3 vs a rewrite, even if the dev team is also already using and well-versed in another language. If you're able to provide more details, please do. It's so rare to have a high-quality discussion about this.
This isn't an issue in 2021. Python 2 reached its EOL over a year ago, and those who own old Python codebases have had known for literally almost 13 years now that Python 2 would be EOL'd when Python 3 came out in 2008.
Deleted Comment
Used correctly - i.e. you’re leaning on structural typing, so you invest your time in Protocols that go “quack” rather than hard-to-test, brittle, nominatively typed Ducks who quack - which incidentally is exactly the path the mypy getting started docs seems to focus on, why?! - that’s just setting people up for failure, i digress.
Mypy, pyright etc are fantastic tools in the toolbox, sure to save time but Cargo culting is a pain to deal with. See for example 2 decades of empty getters / setters in Java “in case we ever want to add some behaviour in future”.
Gradual typing of the structural variety is fantastic, you’ll know if you’re doing it right because you’ll spend surprisingly little time thinking about types, you won’t spend any time wrestling with mypy to convince it of your idea and when it does complain your reaction will be a legitimate “aha, yeah ok fair shout, you got me” not “oh ffs!” :-)
One really cool thing about gradual typing - if you get it wrong and i have to take over your code, i can at least turn it off. One of the reasons i love tests so much - I don’t have to accept yours if they’re a bear to maintain, i can easily bring along my own instead.
For data engineering, I haven't had a chance to try this due to lack of language options, but I strongly suspect that structural typing would be much more useful than nominal typing.
Code in dynamic languages typically takes advantage of the flexibility to do meta-programming, which can significantly both the amount of code required to complete a task and its complexity.
Type inference solves a different problem - it doesn’t help you here. For example
A runtime exception maybe?(There’s no “best” answer here, a runtime exception might be the pragmatic choice but i like the Map<Currency, Amount> solution to this).
I've found that there is no one best typing discipline. Different approaches work better for different problem domains. And I'm currently using Python in so many different problem domains that I find it convenient that Python now allows me to choose the best typing discipline for the job.
It's true that this means that Python isn't the best at any particular way of doing typing. But that also seems appropriate. Being a jack of all trades and master of none is sort of Python's thing nowadays.
And by partial I mean only typing the stuff you end up using, so if you just use one function from some huge, untyped package, just type that one part for now.
The way I see it, you write the stub once, and then the API has less ambiguity and you get type checking.
The only problems I have with them are that they are completely ignored by Python itself - you have to run a separate type checker. That's a fairly stone-aged system. And also I with VSCode had something like Typescript's "no implicit any" so it was more obvious where you had to put types that couldn't be inferred.
What do you expect the Python interpreter to do, exactly? Type annotations are not supposed to affect execution.
In my experience, you may want different type checkers with different configurations for different projects.
Honestly, I don't like the direction Python is taking lately. It used to be easy, approachable, dynamically typed, strongly typed language. Now, syntax is getting polluted and there are definitely more than 2 ways of doing things.