3 ms·

If you don't think the sharp divide between bytes and str in py3 is something new, you haven't grasped the value of it.. I am not sure, you are correct that py

If you don't think the sharp divide between bytes and str in py3 is something new, you haven't grasped the value of it.. I am not sure, you are correct that py2-unicode == py3-str and py3-bytes == py2-str ... But even if (and I must admit that it is more then 5 years since I wrote py2 of any length).. The value is... in py3 "str" is the ideal string, which does things the way humans expect.. When you need to pump in or out bytes, the class is called "bytes" and requires an explicit conversion, where you get prompted to think about encodings.. (but you don't need to think about it all the time as you would with byte-wrangling) This way, people not well-versed in the horrible mess of encodings are going to be safe by default... If they do something unsupported they get an exception, not something that is wrong... That alone is worth it.. Also, the full stack of python is working correctly with unicode, you don't have to handle two different "string" classes ("str" and "unicode") where one of them is like to do the wrong thing.. One often overlook thing is that py3 defaults to utf8 source code, in the old days integrating stuff from files with non-ascii chars in different encodings was a nightmare...

netheril96 9y ago
Sigh, that could have easily been implemented with a "use strict" directive. Or, `from __future__ import strict_unicode`. JavaScript has this strict mode, albeit to solve a different problem, and its success despite its messiness alludes to the notion that gradual improvement is better than sudden breakage.
- acdha 9y ago
  The problem is that the byte-string confusion is widespread. You can import Unicode literals from future but you still need to update every bit of codec which works with files, network sockets, IPC, etc.
- masklinn 9y ago
  > Sigh, that could have easily been implemented with a "use strict" directive. You can already remove the implicit conversion in Python 2 (sys.setdefaultencoding(None)), it will break pretty much every non-trivial software as the standard library itself does not have strict separation and many of its "string" API operate on bytes. > JavaScript has this strict mode, albeit to solve a different problem That it solves a completely different and almost entirely syntactic issue is a bit of a difference there, you'll note that despite all of its changes the ES committee has refused to come even close to touching strings.

netheril96 9y ago

Sigh, that could have easily been implemented with a "use strict" directive. Or, `from __future__ import strict_unicode`. JavaScript has this strict mode, albeit to solve a different problem, and its success despite its messiness alludes to the notion that gradual improvement is better than sudden breakage.

acdha 9y ago
The problem is that the byte-string confusion is widespread. You can import Unicode literals from future but you still need to update every bit of codec which works with files, network sockets, IPC, etc.
masklinn 9y ago
> Sigh, that could have easily been implemented with a "use strict" directive. You can already remove the implicit conversion in Python 2 (sys.setdefaultencoding(None)), it will break pretty much every non-trivial software as the standard library itself does not have strict separation and many of its "string" API operate on bytes. > JavaScript has this strict mode, albeit to solve a different problem That it solves a completely different and almost entirely syntactic issue is a bit of a difference there, you'll note that despite all of its changes the ES committee has refused to come even close to touching strings.