3 ms·

> if it had more features people want What people wanted was features to help with the migration. Yes, that of course having those features would have helped.

> if it had more features people want What people wanted was features to help with the migration. Yes, that of course having those features would have helped. But doing that required experience the Python developers didn't have when they were doing 3.0! The Python developers thought people could do a one-off syntactic code translation (2to3), perhaps even at install time, rather than what most people did - write to the common subset of 2 and 3, with helpers like the 'six' package. What are the "more substantial changes" you propose? The walrus operator? Matching? Other things that Python 3 eventually gained, and which took years in some cases to develop? Or are you proposing something that would have it more difficult to write to the common subset? That subset compatibility necessity extends to the Python/C API. Get rid of global state and you'll need to replace things like: PyErr_SetString(PyExc_ValueError, "embedded null character"); with something that passes in the current execution state. Make that too hard, and you inhibit migration of existing extension modules, which further inhibits the migration.

coldtea 3y ago
>The Python developers thought people could do a one-off syntactic code translation (2to3), perhaps even at install time Perhaps they overstimated how much of the change 2to3 would handle, but they surely didn't think that, because they already knew that they put in all kinds of not automatable via "syntactic code translation" changes - where context is needed (e.g. the str changes). >What are the "more substantial changes" you propose? The walrus operator? Matching? Other things that Python 3 eventually gained, and which took years in some cases to develop? No GIL, more optimization - a wasted opportunity for a big speed bump, dropping legacy stuff, typing support, an improved C extension model, JIT, specialization, green threads, and so on. Things like the walrus operator would be at the very bottom... They could have gone for "compatibility" to ease the migration (or make it a non-issue, just run backwards compatibly) sure. But since they decided to go ahead and break things, and bump the version name, a change the community has been discussing since the mid-90s as some grand vision of big changes, they could have done more substantial stuff at least. At it stands, they broke compatibility and cost the community 5-6 years for nothing much. Everything big came later in 3.x. And not because it couldn't just as well be added piecemeal to some 2.8 and onwards...
- eesmith 3y ago
  > but they surely didn't think that They surely did! And it tells me you don't know the history that well. You can read PEP 3000 where they say almost exactly that, at https://peps.python.org/pep-3000/ https://peps.python.org/pep-3000/ : The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows: 0. You should have excellent unit tests with close to full coverage. 1. Port your project to Python 2.6. 2. Turn on the Py3k warnings mode. 3. Test and edit until no warnings remain. 4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the output! 5. Test the converted source code under 3.0. 6. If problems are found, make corrections to the 2.6 version of the source code and go back to step 3. When it’s time to release, release separate 2.6 and 3.0 tarballs (or whatever archive form you use for releases). They really did not consider having a usable subset that could work on Python 2 and Python 3. The same PEP says: There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.) Remember, it wasn't even until Python 3.3 that they restored the u'unicode' syntax "provided solely to reduce the number of purely mechanical changes in migrating to Python 3, making it easier for developers to focus on the more significant semantic changes (such as the stricter default separation of binary and text data)." https://docs.python.org/3.3/whatsnew/3.3.html https://docs.python.org/3.3/whatsnew/3.3.html And it wasn't until Python 3.5 that they supported old-style %-formatting, like (b"%d" % n), both because it's useful in wire protocols, and "to help ease migration from, and/or have a single code base with, Python 2" https://peps.python.org/pep-0461/ https://peps.python.org/pep-0461/ . > No GIL ... and so on The features you listed required years of development, and some, like the JIT support, are still in-progress, while the no-gil proposal seems beyond what the steering committee is willing to accept. It sounds like you want them to have delivered Python 3.12, with all these features (many of them iterated on over several releases), instead of 3.0, and without any migration path from 2.x Python or Python/C extensions beyond wholesale rewriting. There is no way they would have manged to timely deliver a stable release following your suggestion. As it was, it took about a decade to deliver a version that had a effective migration pathway. Python 3.5 is the first version I supported, in no small part because it supported bytes % interpolation. > And not because it couldn't just as well be added piecemeal to some 2.8 and onwards... Perhaps it could have been done in an abstract and technical sense. But the Python core developers decided they didn't have the resources (money, people, etc) for that path. I don't see how some of the changes, like exception chaining, could have been implemented without breaking backwards compatibility. Even things as simple as evaluating (a<b) or "Hello".encode("base64") changed at a pretty deep level. Remember, Python 3 was always meant as "a relatively mild improvement on Python 2, [because] we can gain a lot by not attempting to reimplement the language from scratch." https://peps.python.org/pep-0461/ https://peps.python.org/pep-0461/ That was how the effort was justified. The Perl6/Raku experience was definitely part of the zeitgeist in the discussion against larger changes like you think were needed. What are your counter-examples that might sooth the concerns should a cusp like this appear in the future? I can't think of any good ones. > and cost the community 5-6 years for nothing much. Everything big came later in 3.x. The core developers argued that the technical debt in the code base was high, and while it would take years, those changes would enable the later big improvements you now see. You seem to look at the big improvements and somehow believe they could have been done 15 years ago, on the old code base, with the available knowledge and resources of the people then. You believe this because, why?

coldtea 3y ago

>The Python developers thought people could do a one-off syntactic code translation (2to3), perhaps even at install time Perhaps they overstimated how much of the change 2to3 would handle, but they surely didn't think that, because they already knew that they put in all kinds of not automatable via "syntactic code translation" changes - where context is needed (e.g. the str changes). >What are the "more substantial changes" you propose? The walrus operator? Matching? Other things that Python 3 eventually gained, and which took years in some cases to develop? No GIL, more optimization - a wasted opportunity for a big speed bump, dropping legacy stuff, typing support, an improved C extension model, JIT, specialization, green threads, and so on. Things like the walrus operator would be at the very bottom... They could have gone for "compatibility" to ease the migration (or make it a non-issue, just run backwards compatibly) sure. But since they decided to go ahead and break things, and bump the version name, a change the community has been discussing since the mid-90s as some grand vision of big changes, they could have done more substantial stuff at least. At it stands, they broke compatibility and cost the community 5-6 years for nothing much. Everything big came later in 3.x. And not because it couldn't just as well be added piecemeal to some 2.8 and onwards...

eesmith 3y ago
> but they surely didn't think that They surely did! And it tells me you don't know the history that well. You can read PEP 3000 where they say almost exactly that, at https://peps.python.org/pep-3000/ https://peps.python.org/pep-3000/ : The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows: 0. You should have excellent unit tests with close to full coverage. 1. Port your project to Python 2.6. 2. Turn on the Py3k warnings mode. 3. Test and edit until no warnings remain. 4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the output! 5. Test the converted source code under 3.0. 6. If problems are found, make corrections to the 2.6 version of the source code and go back to step 3. When it’s time to release, release separate 2.6 and 3.0 tarballs (or whatever archive form you use for releases). They really did not consider having a usable subset that could work on Python 2 and Python 3. The same PEP says: There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.) Remember, it wasn't even until Python 3.3 that they restored the u'unicode' syntax "provided solely to reduce the number of purely mechanical changes in migrating to Python 3, making it easier for developers to focus on the more significant semantic changes (such as the stricter default separation of binary and text data)." https://docs.python.org/3.3/whatsnew/3.3.html https://docs.python.org/3.3/whatsnew/3.3.html And it wasn't until Python 3.5 that they supported old-style %-formatting, like (b"%d" % n), both because it's useful in wire protocols, and "to help ease migration from, and/or have a single code base with, Python 2" https://peps.python.org/pep-0461/ https://peps.python.org/pep-0461/ . > No GIL ... and so on The features you listed required years of development, and some, like the JIT support, are still in-progress, while the no-gil proposal seems beyond what the steering committee is willing to accept. It sounds like you want them to have delivered Python 3.12, with all these features (many of them iterated on over several releases), instead of 3.0, and without any migration path from 2.x Python or Python/C extensions beyond wholesale rewriting. There is no way they would have manged to timely deliver a stable release following your suggestion. As it was, it took about a decade to deliver a version that had a effective migration pathway. Python 3.5 is the first version I supported, in no small part because it supported bytes % interpolation. > And not because it couldn't just as well be added piecemeal to some 2.8 and onwards... Perhaps it could have been done in an abstract and technical sense. But the Python core developers decided they didn't have the resources (money, people, etc) for that path. I don't see how some of the changes, like exception chaining, could have been implemented without breaking backwards compatibility. Even things as simple as evaluating (a<b) or "Hello".encode("base64") changed at a pretty deep level. Remember, Python 3 was always meant as "a relatively mild improvement on Python 2, [because] we can gain a lot by not attempting to reimplement the language from scratch." https://peps.python.org/pep-0461/ https://peps.python.org/pep-0461/ That was how the effort was justified. The Perl6/Raku experience was definitely part of the zeitgeist in the discussion against larger changes like you think were needed. What are your counter-examples that might sooth the concerns should a cusp like this appear in the future? I can't think of any good ones. > and cost the community 5-6 years for nothing much. Everything big came later in 3.x. The core developers argued that the technical debt in the code base was high, and while it would take years, those changes would enable the later big improvements you now see. You seem to look at the big improvements and somehow believe they could have been done 15 years ago, on the old code base, with the available knowledge and resources of the people then. You believe this because, why?