Hacker News Reader

Comment by ASalazarMX | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com