News for hackers. Stuff that matters.
Re:Adoption of Mypy for Python type checking: 45% already us... by midrus on Sunday March 21, 2021 @10:55AM (#26530897)
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.

Re:Adoption of Mypy for Python type checking: 45% already us... by johnnycerberus on Sunday March 21, 2021 @12:18PM (#26531497)
I think your comment is a little bit alarmist.

* 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

Re:Adoption of Mypy for Python type checking: 45% already us... by dragonwriter on Sunday March 21, 2021 @07:25PM (#26535085)
> 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

Not really. TypeScript is a JS superset (and TypeScript tooling works with unadorned JS, too), but Coffee script/Reason are incompatible languages that happen to compile to JS and have static typing. All of the Python typecheckers are more like TypeScript, except that even the type annotations and much of the type system is also standardized as part of the core language. You can literally use any of them on the same code base, and get largely the same results (some will catch some type errors that others miss, some will flag some correct code as possibly erroneous that others would leave alone, but the differences tend to be minor.)

Re:Adoption of Mypy for Python type checking: 45% already us... by joshuamorton on Sunday March 21, 2021 @02:03PM (#26532436)
Pytype (Google) pyre (facebook) and pyright (microsoft) all have more institutional backing than mypy. They aren't going away anytime soon.

Otoh, development of all the major type checkers is fairly collaborative. Mypy usually gets features first, but not always.

Re:Adoption of Mypy for Python type checking: 45% already us... by spicybright on Sunday March 21, 2021 @06:44PM (#26534857)
Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.
Re:Adoption of Mypy for Python type checking: 45% already us... by joshuamorton on Sunday March 21, 2021 @07:16PM (#26535029)
They have different goals. Pytype does inference, which allows easier bootstrapping. Pyre is fast and supports some nonstandard control flow and taint flow stuff. Pyright supports partial validation for syntactically broken files, for use as part of an ide.
Re:Adoption of Mypy for Python type checking: 45% already us... by dragonwriter on Sunday March 21, 2021 @07:29PM (#26535103)
> Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.

Instead, the approach seems to be adopting a standardized system of type annotations into the standard library. While a typechecker may expose a library interface, it's main use is as an executable tool, not a library (unlike annotations themselves), so it's not super critical to have one in the standard library. It might be convenient to have it in the standard distribution, but as a practical matter it's not like there is a problem getting at least one of them that does a suitable job with standard type annotations anywhere you can get Python.

Re:Adoption of Mypy for Python type checking: 45% already us... by heavyset_go on Sunday March 21, 2021 @07:37PM (#26535152)
Check out the typing module[1] from the Python standard library. A lot of it was adopted directly from Mypy.

[1] https://docs.python.org/3/library/typing.html

Re:Adoption of Mypy for Python type checking: 45% already us... by maple3142 on Sunday March 21, 2021 @12:48PM (#26531761)
> what does async vs blocking even mean in this context? all languages have the same problem, just use the libraries that are non-blocking.

Maybe Node.js? Although it does have some sync function to do io, most of them are still unblocking, and the ecosystem is unblocking by default too. It is harder to find a blocking library than finding a non-blocking ones.

Re:Adoption of Mypy for Python type checking: 45% already us... by Izkata on Monday March 22, 2021 @08:37PM (#26549459)
> * Python 2 is dead.

Officially yes, but in terms of actual use? Not really. Plenty of legacy codebases are still around that don't have the resources to upgrade.

Re:Adoption of Mypy for Python type checking: 45% already us... by elcritch on Sunday March 21, 2021 @10:34PM (#26536257)
Async vs blocking functions aren't a thing in Erlang and Elixir because everything (almost) is non-blocking.
Re:Adoption of Mypy for Python type checking: 45% already us... by guitarbill on Sunday March 21, 2021 @12:12PM (#26531450)
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.

Re:Adoption of Mypy for Python type checking: 45% already us... by AlphaSite on Sunday March 21, 2021 @11:35AM (#26531200)
Python 2 is pretty dead at this point.
Re:Adoption of Mypy for Python type checking: 45% already us... by e3k on Sunday March 21, 2021 @07:18PM (#26535043)
2.x dead? Not really: lots of 10 year old projects are in maintenance or even actively developed.

Migrating several hundred thousand lines of code bases with few people and many dependencies (some of them not maintained, not ported to 3) are not trivial.

These will stay for years still. Actually it is very sad, that significant new tools are basically useless on 2.x (e.g. vscode: lots of waiting on completion, or jumping to definition - if it works at all).

Re:Adoption of Mypy for Python type checking: 45% already us... by heavyset_go on Sunday March 21, 2021 @04:33PM (#26533723)
> Python 2 vs 3

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.