20 ms·

I strongly disagree: decoding and recoding strings to-from UTF8 was a monumental waste of time IMO. Never has one language gave so much trouble for simple tasks

I strongly disagree: decoding and recoding strings to-from UTF8 was a monumental waste of time IMO. Never has one language gave so much trouble for simple tasks like reading a database. Python3 just works seamlessly.

loeg 7y ago
Implementation details of u"" could be changed without rototilling the language. Breaking the print statement does not improve unicode support, for example.
- airstrike 7y ago
  The change to the print statement is an absolutely trivial for any project. Literally all you have to do is type in "2to3 foo.py". Boom, done.
- takeda 7y ago
  All the people that are crying about print() never did any migration. That's the easiest part, it can be fully automated. In fact you will almost never use print in any serious program. The unicode is the most difficult part of the migration, because most of python 2 code is actually broken, it can't be automated because you need to know what you want whether you need text or bytes.
jzwinck 7y ago
In Python 3 if you have bytes and write them out using the "csv" module, you get something like this: b'A',b'B' b'1',b'2' That's not seamless, and I wouldn't say it helps non-English speakers either. This bug impacts Pandas to_csv as well.
- deleted 7y ago
  [deleted]
- agoodthrowaway 7y ago
  Sorry but I don’t agree this is a bug. You need to decode your bytes to properly write a string. Otherwise you get the unexpected result you are showing because it has no way of knowing how your bytes are encoded.
- ASalazarMX 7y ago
  But bytes are not strings. Unless you convert them to a string first, they could be an image, a sound, a certificate, etc. Since ASCII strings are always one byte per character, they can be manipulated as bytes, but UTF8 strings aren't. In Python3 you operate with strings and always get strings, you operate with bytes and always get bytes. The string = byte array pattern is an atavism that should not exist this century.

loeg 7y ago

Implementation details of u"" could be changed without rototilling the language. Breaking the print statement does not improve unicode support, for example.

airstrike 7y ago
The change to the print statement is an absolutely trivial for any project. Literally all you have to do is type in "2to3 foo.py". Boom, done.
takeda 7y ago
All the people that are crying about print() never did any migration. That's the easiest part, it can be fully automated. In fact you will almost never use print in any serious program. The unicode is the most difficult part of the migration, because most of python 2 code is actually broken, it can't be automated because you need to know what you want whether you need text or bytes.

jzwinck 7y ago

In Python 3 if you have bytes and write them out using the "csv" module, you get something like this: b'A',b'B' b'1',b'2' That's not seamless, and I wouldn't say it helps non-English speakers either. This bug impacts Pandas to_csv as well.

deleted 7y ago
[deleted]
agoodthrowaway 7y ago
Sorry but I don’t agree this is a bug. You need to decode your bytes to properly write a string. Otherwise you get the unexpected result you are showing because it has no way of knowing how your bytes are encoded.
ASalazarMX 7y ago
But bytes are not strings. Unless you convert them to a string first, they could be an image, a sound, a certificate, etc. Since ASCII strings are always one byte per character, they can be manipulated as bytes, but UTF8 strings aren't. In Python3 you operate with strings and always get strings, you operate with bytes and always get bytes. The string = byte array pattern is an atavism that should not exist this century.