5 ms·

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 ag

by midrus 6y ago

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.

AlphaSite 6y ago
Python 2 is pretty dead at this point.
- e3k 6y ago
  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).
guitarbill 6y ago
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.
johnnycerberus 6y ago
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
- maple3142 6y ago
  > 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.
- joshuamorton 6y ago
  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.
  - spicybright 6y ago
    Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.
    - dragonwriter 6y ago
      > 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.
heavyset_go 6y ago
> 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.

by midrus 6y ago

AlphaSite 6y ago

Python 2 is pretty dead at this point.

e3k 6y ago
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).

guitarbill 6y ago

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.

johnnycerberus 6y ago

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

maple3142 6y ago
> 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.
joshuamorton 6y ago
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.
- spicybright 6y ago
  Why not just adopt one into the standard library, seems like a very obvious battery you'd want to include.
  - dragonwriter 6y ago
    > 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.

heavyset_go 6y ago

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