5 ms·

Python tried to pull a Perl 6 and failed. Python 3 was done as a flag day, a big breaking change you need to switch over to. Originally Python 3 and Python 2 la

Python tried to pull a Perl 6 and failed. Python 3 was done as a flag day, a big breaking change you need to switch over to. Originally Python 3 and Python 2 lacked features that would make it possible to write code that is compatible with both versions (like `u"foo"` syntax). Slowly they added things to Python 2 and 3 to make it easier to slowly transition. But it was still full of unnecessary breaking changes. - The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use. - A lot of the incompatibilities are just stdlib modules being moved around unnecessarily. They could have made both import paths work for a transitional (deprecation) period. Or let the old paths continue to work forever, and just document usage of the new paths. - All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2. The only true breaking change was unicode literal strings. But again, that could be handled with a slow transitional (deprecation) period. The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have). And users could have been told to `from __future__ import unicode_literals` for a transitional (deprecation) period, to ensure their code is compatible before it becomes the default. Basically Python 3 could have been a single hard breaking change (unicode literal strings), with a smooth transition. Instead they decided to make Python 2 and 3 diverge from each other, making it harder to do the transition.

mcv 6y ago
I think next time, when you need to do breaking changes, give it a new name, so the new thing gets to be hot and new, rather than a problem. Or do what javascript did: stay compatible with the stupid old way, but build a brand new language on top of it.
- b2gills 6y ago
  That's exactly what Perl has been doing since 1987. Where do you think the idea for `"use strict"` in JavaScript came from? use v5.8; use strict; use warnings;
joshuamorton 6y ago
> The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use. They did, it's from __future__ import print_function. python2.7 was, essentially, the transitional deprecation period you mention, and it lasted a decade. > A lot of the incompatibilities are just stdlib modules being moved around unnecessarily. six.moves > - All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2. This assumes a level of similarity in the py2 and py3 codebases that isn't true in practice. There are different bytecodes and 3.0 only optimizations. Backporting some of these is possible, but not a reasonable burden. >The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have). I don't know what you're working with, but most third party libs aren't compatible with both types of strings. They're compatible with str or bytes, but not both except in rare and usually wrong cases. Importing unicode literals only sometimes solves the issues, and often times introduces different problems.
musicale 6y ago
> - The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use. The print statement dates to antiquity (cf. BASIC) and could certainly coexist with the print() function. It was a nice and friendly piece of syntax whose removal was entirely unnecessary. Now that Python is free of GVR, perhaps we can restore the print statement to its rightful place in the language! ;D

mcv 6y ago

I think next time, when you need to do breaking changes, give it a new name, so the new thing gets to be hot and new, rather than a problem. Or do what javascript did: stay compatible with the stupid old way, but build a brand new language on top of it.

b2gills 6y ago
That's exactly what Perl has been doing since 1987. Where do you think the idea for `"use strict"` in JavaScript came from? use v5.8; use strict; use warnings;

joshuamorton 6y ago

> The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use. They did, it's from __future__ import print_function. python2.7 was, essentially, the transitional deprecation period you mention, and it lasted a decade. > A lot of the incompatibilities are just stdlib modules being moved around unnecessarily. six.moves > - All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2. This assumes a level of similarity in the py2 and py3 codebases that isn't true in practice. There are different bytecodes and 3.0 only optimizations. Backporting some of these is possible, but not a reasonable burden. >The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have). I don't know what you're working with, but most third party libs aren't compatible with both types of strings. They're compatible with str or bytes, but not both except in rare and usually wrong cases. Importing unicode literals only sometimes solves the issues, and often times introduces different problems.

musicale 6y ago

> - The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use. The print statement dates to antiquity (cf. BASIC) and could certainly coexist with the print() function. It was a nice and friendly piece of syntax whose removal was entirely unnecessary. Now that Python is free of GVR, perhaps we can restore the print statement to its rightful place in the language! ;D