4 ms·

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.

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.