5 ms·

What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have

What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python3/ https://fosdem.org/2018/schedule/event/python3/

VeejayRampay 9y ago
The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
- stealthcat 9y ago
  Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
  - ComputerGuru 9y ago
    “Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.
- toyg 9y ago
  That massive chip on your shoulder is weighing you down. If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare. There might be some good lessons there.
- simonh 9y ago
  I do not think double standard means what you think it means.
- jamesgeck0 9y ago
  Ruby had 1.9. It was like the Python 3 situation in miniature, and Matz has said he’s keen to avoid such a mistake again.
  - takeda 9y ago
    It also was in a minor version change 1.8 -> 1.9, but people moved on because 1.8 was declared EOL this is what Python was missing. Python 3 is 10 years old and 2.7 is still supported (bufixes, but still). If you look at timing, Python 3 picked up for new projects in 2015, when PSF declared that no new features will be backported to Python 2 from 3. I believe the industry will wait for 2020 to start migrating existing code after Python 2.7 will be declared EOL.
- username223 9y ago
  Those three scripting languages actually an interesting comparison. Perl 5 -> 6 broke all your code in exchange for a whole new language. Some people moved to Perl 6, some to other languages, and a lot stayed with Perl (5), which still runs programs written in Perl 1. Ruby 1.8 -> 1.9 broke most of your code in exchange for minor cleanups. But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along. Python 2 -> 3 also broke most of your code in exchange for minor cleanups. Users expected some stability, but the language's culture demanded conformity. The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3.
  - kec 9y ago
    > The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3. I think that's the most succinct way to put this whole debacle I've ever seen. I'm totally stealing this.
  - irishsultan 9y ago
    > But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along. The main reason people switched probably wasn't rails making people expect breakage, the main reason was that (a) it was relatively easy to rewrite your code to work on both 1.8 and 1.9 (as long as your dependencies had already done it), and (b) 1.9 was much faster.
hyperpallium 9y ago
Could someone provide a summary of the kinds of mistakes/remedies?
- takeda 9y ago
  Did not watch the presentation but IMO the primary mistake was not declaring EOL for 2.x sooner. Other languages had similarly breaking changes and they simply gave short time before legacy version was declared EOL and developers ported their applications to the new version. In Python it took 10 years, and even now you can't get companies to migrate, because why make developers do the work when application still can be used. Many places will probably start the migration in 2020, which shows that giving 10 years head start was a mistake and all it did was create FUD and division in the community. The Python 3 immediately picked up for new projects after announcement that 2.7 will no longer have new feature and only bugfixes in 2015. Industry will wait for the last moment when all support for 2.7 will be ceased in 2020.
  - collinmanderson 9y ago
    For the record, Python 2.7 EOL was originally 2015. In 2014, it was moved later, likely because RedHat would continue to maintain it for free anyway. https://legacy.python.org/dev/peps/pep-0373/#id2 https://legacy.python.org/dev/peps/pep-0373/#id2
- ceronman 9y ago
  One mistake was providing 2to3 as a migration path. This required projects to move completely from 2 to 3, for libraries it meant that they had to either stop supporting 2 (which were the majority of their users) or forking and maintaining both versions. The remedy was to make it possible for libraries to be both 2.7 and 3.x compatible, using tools such as six.py and making some changes to 3.x to make it more compatible with 2 (e.g. adding u'' strings).
  - Too 9y ago
    The problem with six is that once you decide to use it your entire code base must be written with the lowest common denominator in mind, in this case py2.7. You can't use six.py at the interface boundaries and nice python3 features inside your implementation. Six is only useful for old 2.7 libraries that want to quickly be 3.x compatible and still maintain their 2.7 compatibility, not if you have an old 2.7 application and want to incrementally add 3.x features. The proper way make a major breaking change like python did is to provide a bridge between the two versions, so you could import 2.7 modules from 3.x applications, and even the other way around. As of today there is still no such thing.

VeejayRampay 9y ago

The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.

stealthcat 9y ago
Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
- ComputerGuru 9y ago
  “Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.
toyg 9y ago
That massive chip on your shoulder is weighing you down. If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare. There might be some good lessons there.
simonh 9y ago
I do not think double standard means what you think it means.
jamesgeck0 9y ago
Ruby had 1.9. It was like the Python 3 situation in miniature, and Matz has said he’s keen to avoid such a mistake again.
- takeda 9y ago
  It also was in a minor version change 1.8 -> 1.9, but people moved on because 1.8 was declared EOL this is what Python was missing. Python 3 is 10 years old and 2.7 is still supported (bufixes, but still). If you look at timing, Python 3 picked up for new projects in 2015, when PSF declared that no new features will be backported to Python 2 from 3. I believe the industry will wait for 2020 to start migrating existing code after Python 2.7 will be declared EOL.
username223 9y ago
Those three scripting languages actually an interesting comparison. Perl 5 -> 6 broke all your code in exchange for a whole new language. Some people moved to Perl 6, some to other languages, and a lot stayed with Perl (5), which still runs programs written in Perl 1. Ruby 1.8 -> 1.9 broke most of your code in exchange for minor cleanups. But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along. Python 2 -> 3 also broke most of your code in exchange for minor cleanups. Users expected some stability, but the language's culture demanded conformity. The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3.
- kec 9y ago
  > The result has been a decade-long war in which Python fans try to shame Python users into moving to version 3. I think that's the most succinct way to put this whole debacle I've ever seen. I'm totally stealing this.
- irishsultan 9y ago
  > But Ruby was Rails, so the culture accepted constant rewriting and breakage, and people went along. The main reason people switched probably wasn't rails making people expect breakage, the main reason was that (a) it was relatively easy to rewrite your code to work on both 1.8 and 1.9 (as long as your dependencies had already done it), and (b) 1.9 was much faster.

hyperpallium 9y ago

Could someone provide a summary of the kinds of mistakes/remedies?

takeda 9y ago
Did not watch the presentation but IMO the primary mistake was not declaring EOL for 2.x sooner. Other languages had similarly breaking changes and they simply gave short time before legacy version was declared EOL and developers ported their applications to the new version. In Python it took 10 years, and even now you can't get companies to migrate, because why make developers do the work when application still can be used. Many places will probably start the migration in 2020, which shows that giving 10 years head start was a mistake and all it did was create FUD and division in the community. The Python 3 immediately picked up for new projects after announcement that 2.7 will no longer have new feature and only bugfixes in 2015. Industry will wait for the last moment when all support for 2.7 will be ceased in 2020.
- collinmanderson 9y ago
  For the record, Python 2.7 EOL was originally 2015. In 2014, it was moved later, likely because RedHat would continue to maintain it for free anyway. https://legacy.python.org/dev/peps/pep-0373/#id2 https://legacy.python.org/dev/peps/pep-0373/#id2
ceronman 9y ago
One mistake was providing 2to3 as a migration path. This required projects to move completely from 2 to 3, for libraries it meant that they had to either stop supporting 2 (which were the majority of their users) or forking and maintaining both versions. The remedy was to make it possible for libraries to be both 2.7 and 3.x compatible, using tools such as six.py and making some changes to 3.x to make it more compatible with 2 (e.g. adding u'' strings).
- Too 9y ago
  The problem with six is that once you decide to use it your entire code base must be written with the lowest common denominator in mind, in this case py2.7. You can't use six.py at the interface boundaries and nice python3 features inside your implementation. Six is only useful for old 2.7 libraries that want to quickly be 3.x compatible and still maintain their 2.7 compatibility, not if you have an old 2.7 application and want to incrementally add 3.x features. The proper way make a major breaking change like python did is to provide a bridge between the two versions, so you could import 2.7 modules from 3.x applications, and even the other way around. As of today there is still no such thing.