4 ms·

The thing is they could have done so much more with breaking changes. They could have fixed the broken module system, removed the GIL or improved performance by

The thing is they could have done so much more with breaking changes. They could have fixed the broken module system, removed the GIL or improved performance by an order of magnitude by removing language features that almost nobody uses but prevent important optimizations. Instead they caused a huge rift in the Python community and 10+ years of continued pain for what? Improved unicode support and removing the ability to type "print x"?

bluGill 7y ago
What of those things are implementation details that don't need a new language to fix though? Jpython has never had the GIL, there is no reason you can't remove it from python without doing a breaking change as well. (it might break buggy programs by python can carefully never promised you can rely on the GIL) You claim there are language features to remove, if true you are correct they should have done that. That said in my experience most outsiders claiming some "rarely used" feature is the cause of some slowness don't have data to back their claims up. Often the feature is in fact used by some important subset. Often the feature isn't the cause of any slowdown. Improved unicode support is a very good thing to have. Maybe you don't have to support users outside of Western Europe and the Americas where ascii works well enough. (this also excludes various native languages in the Americas and assumes the non-English marks on various letters can be ignored) Anyone who can't do that is glad to not have to fight Unicode in python. "print x" is a minor thing, but it makes the language better for the stated goals.
- mytherin 7y ago
  For many of these things indeed it is about the internal implementation and not about the language itself (although the language itself has many features limiting optimizations as well). The main problem is that modules are compiled against the CPython implementation and the CPython API. These inefficiencies can never be fixed without changing the CPython API. However, changing that API means breaking all the modules that are compiled against that API. This is also the reason why other interpreters besides the CPython one have so much trouble supporting all modules. They basically need to either rewrite the module code or support the (very inefficient) CPython API. They could have changed the API to allow for much more efficient Python programs when they made the breaking transition of Python 2 to Python 3. However, instead they changed only a very small part of the API (the strings/unicode part) and left everything else intact. This meant it was easier to change code to support Python 3, however, it also means the actual benefits of switching to Python 3 are very limited while still breaking every single module that was compiled against Python 2. This basically brings us to todays situation where billions of lines of code need to be updated to work on Python 3 (many of which will never be updated), while basically barely getting any benefits for doing so. Yes, improved unicode support is great and I won't argue that it is an improvement, but arguing that it's worth millions of hours and millions of dollars wasted on upgrading code is a very hard sell. Breaking backwards compatibility is very, very dangerous for popular projects, and it is something that should be taken extremely seriously. The team behind the Python 2 to Python 3 transition clearly did not do that, and the entire Python community has paid the price for that. The "print x" thing makes it extremely obvious that they did not realize the huge impact of their decision to break backwards compatibility. It is a minor thing that fixes a problem that really wasn't there to begin with, but it's a minor thing that breaks almost every single Python 2 program ever written. It's just ridiculous.

bluGill 7y ago

What of those things are implementation details that don't need a new language to fix though? Jpython has never had the GIL, there is no reason you can't remove it from python without doing a breaking change as well. (it might break buggy programs by python can carefully never promised you can rely on the GIL) You claim there are language features to remove, if true you are correct they should have done that. That said in my experience most outsiders claiming some "rarely used" feature is the cause of some slowness don't have data to back their claims up. Often the feature is in fact used by some important subset. Often the feature isn't the cause of any slowdown. Improved unicode support is a very good thing to have. Maybe you don't have to support users outside of Western Europe and the Americas where ascii works well enough. (this also excludes various native languages in the Americas and assumes the non-English marks on various letters can be ignored) Anyone who can't do that is glad to not have to fight Unicode in python. "print x" is a minor thing, but it makes the language better for the stated goals.

mytherin 7y ago
For many of these things indeed it is about the internal implementation and not about the language itself (although the language itself has many features limiting optimizations as well). The main problem is that modules are compiled against the CPython implementation and the CPython API. These inefficiencies can never be fixed without changing the CPython API. However, changing that API means breaking all the modules that are compiled against that API. This is also the reason why other interpreters besides the CPython one have so much trouble supporting all modules. They basically need to either rewrite the module code or support the (very inefficient) CPython API. They could have changed the API to allow for much more efficient Python programs when they made the breaking transition of Python 2 to Python 3. However, instead they changed only a very small part of the API (the strings/unicode part) and left everything else intact. This meant it was easier to change code to support Python 3, however, it also means the actual benefits of switching to Python 3 are very limited while still breaking every single module that was compiled against Python 2. This basically brings us to todays situation where billions of lines of code need to be updated to work on Python 3 (many of which will never be updated), while basically barely getting any benefits for doing so. Yes, improved unicode support is great and I won't argue that it is an improvement, but arguing that it's worth millions of hours and millions of dollars wasted on upgrading code is a very hard sell. Breaking backwards compatibility is very, very dangerous for popular projects, and it is something that should be taken extremely seriously. The team behind the Python 2 to Python 3 transition clearly did not do that, and the entire Python community has paid the price for that. The "print x" thing makes it extremely obvious that they did not realize the huge impact of their decision to break backwards compatibility. It is a minor thing that fixes a problem that really wasn't there to begin with, but it's a minor thing that breaks almost every single Python 2 program ever written. It's just ridiculous.