4 ms·

In an interesting parallel universe, Python 3.0 was released with only two changes, namely the UTF-8 system, and no "old-school" classes. Nothing else was adde

In an interesting parallel universe, Python 3.0 was released with only two changes, namely the UTF-8 system, and no "old-school" classes. Nothing else was added, and no features were removed. It was a huge success, and the whole community switched over in about a year. Each new release added features, but there was much less wailing, sarcastic blog posts and gnashing of teeth. Due to quantum, and lots of sci-fi nonsense, that universe is slowly distorting this one until eventually python3 reaches it's state of historical 'rightness'. In a few years time, all of time and space itself will only reflect this new reality, except for a small number of blogposts about how "Python3k will never take off" which will sit silent and forgottern, a mere curiosity in the endless halls of cyberspace.

masklinn 13y ago
> namely the UTF-8 system What are you talking about here? Is it the FSR introduced in 3.3, or the split between unicode and byte strings? Because if the latter > and the whole community switched over in about a year. must have been written under influence, the unicode/bytes semantics split and inability to play fast and loose with the definition of "string" in P3 is by far the biggest difficulty when switching between P2 and P3[0]. And that split and the backwards incompatibility it generated is pretty much the reason why the core team felt adding further non-BC features was OK: there was no way usual non-trivial P2 code would work on P3 in the first place (especially since this was in the 2.6 release cycle, most of the backports were added later in 2.7), so they may as well clean up the language and stdlib while at it. [0] and the reason why most libraries didn't work OOTB, and why some protocol — WSGI for instance — had to be rethought in-depth to try and understand what is and is not a string.
- ygra 13y ago
  > inability to play fast and lose with the definition of "string" If that wasn't intentional it's a very fitting typo. In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs which tends to work somewhat until it breaks (similar to string handling in C/C++ when Unicode is encountered).
  - masklinn 13y ago
    > If that wasn't intentional it's a very fitting typo. It wasn't[0], and though I agree I fixed it. > In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs Yes, although it really annoys people who work at the boundary or in domains where the distinction is unclear or ill-defined (urls, HTTP headers, environment variables, …). Which is probably why e.g. Armin Ronacher has so many issues with it[1]: the vast majority of his stuff (at least for the libraries he releases) operate across these boundaries. [0] I actually spent a second wondering, and then I got it wrong anyway. [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
- penguindev 13y ago
  And it still scares me that python 3 has hackery to fake unicode dirlistings on unix. (surrogate escaping - pep-0383). I guarantee that will bite people in the ass and cause security bugs. 'explicit is better than implicit' - hah.
lclarkmichalek 13y ago
Really? In my experience, dealing with the changes to Unicode handling are usually the sole non trivial change when handling py2k and 3k from the same codebase. Everything else is just a case of either import six, or writing a little (sub 50 line) compat module. Of course, I imagine things get more interesting if you fiddle with cpython internals a lot, but those cases are in the minority.
dalke 13y ago
It took over a year for the whole community to switch from 1.x to 2.x, and the differences between those is much smaller than the UTF-8 system. (Eg, one of my clients had code with "import *" inside of functions, which no longer worked with 2.x. This syntax error alone was enough to keep them on 1.5.4 for a long time, before finally committing time to make the change.)
marcosdumay 13y ago
> only two changes, namely the UTF-8 system, and no "old-school" classes I like the new import semantics a lot. It removed all ambiguity from the old one.

masklinn 13y ago

> namely the UTF-8 system What are you talking about here? Is it the FSR introduced in 3.3, or the split between unicode and byte strings? Because if the latter > and the whole community switched over in about a year. must have been written under influence, the unicode/bytes semantics split and inability to play fast and loose with the definition of "string" in P3 is by far the biggest difficulty when switching between P2 and P3[0]. And that split and the backwards incompatibility it generated is pretty much the reason why the core team felt adding further non-BC features was OK: there was no way usual non-trivial P2 code would work on P3 in the first place (especially since this was in the 2.6 release cycle, most of the backports were added later in 2.7), so they may as well clean up the language and stdlib while at it. [0] and the reason why most libraries didn't work OOTB, and why some protocol — WSGI for instance — had to be rethought in-depth to try and understand what is and is not a string.

ygra 13y ago
> inability to play fast and lose with the definition of "string" If that wasn't intentional it's a very fitting typo. In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs which tends to work somewhat until it breaks (similar to string handling in C/C++ when Unicode is encountered).
- masklinn 13y ago
  > If that wasn't intentional it's a very fitting typo. It wasn't[0], and though I agree I fixed it. > In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs Yes, although it really annoys people who work at the boundary or in domains where the distinction is unclear or ill-defined (urls, HTTP headers, environment variables, …). Which is probably why e.g. Armin Ronacher has so many issues with it[1]: the vast majority of his stuff (at least for the libraries he releases) operate across these boundaries. [0] I actually spent a second wondering, and then I got it wrong anyway. [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
penguindev 13y ago
And it still scares me that python 3 has hackery to fake unicode dirlistings on unix. (surrogate escaping - pep-0383). I guarantee that will bite people in the ass and cause security bugs. 'explicit is better than implicit' - hah.

lclarkmichalek 13y ago

Really? In my experience, dealing with the changes to Unicode handling are usually the sole non trivial change when handling py2k and 3k from the same codebase. Everything else is just a case of either import six, or writing a little (sub 50 line) compat module. Of course, I imagine things get more interesting if you fiddle with cpython internals a lot, but those cases are in the minority.

dalke 13y ago

It took over a year for the whole community to switch from 1.x to 2.x, and the differences between those is much smaller than the UTF-8 system. (Eg, one of my clients had code with "import *" inside of functions, which no longer worked with 2.x. This syntax error alone was enough to keep them on 1.5.4 for a long time, before finally committing time to make the change.)

marcosdumay 13y ago

> only two changes, namely the UTF-8 system, and no "old-school" classes I like the new import semantics a lot. It removed all ambiguity from the old one.