4 ms·

With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Pyt

With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.

MangoToupe 11mo ago
> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.
- JoshTriplett 11mo ago
  It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
  - MangoToupe 11mo ago
    I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
- SoftTalker 11mo ago
  Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
  - deleted 11mo ago
    [deleted]
  - MangoToupe 11mo ago
    Yes, exactly. customers need to stop acting like a bitch if they wanna be taken seriously
kstrauser 11mo ago
That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes. Being more or less forced to decode that series into a string of text where appropriate made a huge number of bugs vanish. Oops, forget to run `value=incoming_data.decode()` before passing incoming data to a function that expects a string, not a series of bytes? Boom! Thing is, it was always broken, but now it's visibly broken. And there was no more having to remember if you'd already .decode()d a value or whether you still needed to, because the end result isn't the same datatype anymore. It was so annoying to have an internal function in a webserver, and the old sloppiness meant that sometimes you were calling it with decoded strings and sometimes the raw bytes coming in over the wire, so sometimes it processed non-ASCII characters incorrectly, and if you tried to fix it by making it decode passed-in values, it start started breaking previously-working callers. Ugh, what a mess! I hated the schism for about the first month because it broke a lot of my old, crappy code. Well, it didn't actually. It just forced me to be aware of my old, crappy code, and do the hard, non-automatable work of actually fixing it. The end result was far better than what I'd started with.
- JoshTriplett 11mo ago
  That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
  - kstrauser 11mo ago
    I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.
    - JoshTriplett 11mo ago
      The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them. I'm suggesting a model in which one interpreter runs both Python 2 and Python 3, and the underlying types are the same, so you can pass them between the two. You'd have to know that "foo" created in Python 2 is the equivalent of b"foo" created in Python 3, but that's easy enough to deal with.
zahlman 11mo ago
Why would I ever risk inflicting a stack trace like Traceback (most recent call last): File "x.py", line 2, in <module> foo.encode() UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) on a user of Python 3.x where it isn't possible? (Note the UnicodeDecodeError coming from an attempt to encode.)

MangoToupe 11mo ago

> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.

JoshTriplett 11mo ago
It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
- MangoToupe 11mo ago
  I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
SoftTalker 11mo ago
Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
- deleted 11mo ago
  [deleted]
- MangoToupe 11mo ago
  Yes, exactly. customers need to stop acting like a bitch if they wanna be taken seriously

kstrauser 11mo ago

That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes. Being more or less forced to decode that series into a string of text where appropriate made a huge number of bugs vanish. Oops, forget to run `value=incoming_data.decode()` before passing incoming data to a function that expects a string, not a series of bytes? Boom! Thing is, it was always broken, but now it's visibly broken. And there was no more having to remember if you'd already .decode()d a value or whether you still needed to, because the end result isn't the same datatype anymore. It was so annoying to have an internal function in a webserver, and the old sloppiness meant that sometimes you were calling it with decoded strings and sometimes the raw bytes coming in over the wire, so sometimes it processed non-ASCII characters incorrectly, and if you tried to fix it by making it decode passed-in values, it start started breaking previously-working callers. Ugh, what a mess! I hated the schism for about the first month because it broke a lot of my old, crappy code. Well, it didn't actually. It just forced me to be aware of my old, crappy code, and do the hard, non-automatable work of actually fixing it. The end result was far better than what I'd started with.

JoshTriplett 11mo ago
That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
- kstrauser 11mo ago
  I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.
  - JoshTriplett 11mo ago
    The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them. I'm suggesting a model in which one interpreter runs both Python 2 and Python 3, and the underlying types are the same, so you can pass them between the two. You'd have to know that "foo" created in Python 2 is the equivalent of b"foo" created in Python 3, but that's easy enough to deal with.

zahlman 11mo ago

Why would I ever risk inflicting a stack trace like Traceback (most recent call last): File "x.py", line 2, in <module> foo.encode() UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) on a user of Python 3.x where it isn't possible? (Note the UnicodeDecodeError coming from an attempt to encode.)