Hacker News Reader

Comment by tick_tock_tick | Hacker News Reader

While you should move on to python3 at this point I still stand by the whole thing was a giant waste of time. 'Better' unicode support was not worth the mess. Everything else could have been done in python2.

View on HN

That's only if you are dealing with an US English userbase who never copy/paste from Microsoft Word. Anything else, and the better unicode support is a godsend. Better have them pop up as type errors during development than as uncaught exceptions whenever a user happens to first put unicode somewhere you don't expect.

Not just non-US users, but also emojis.

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.

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.

I think in hindsight v3 mode could be enabled per file, rather than per program.

That wasn't done, but for reasons that amount to "we don't want to"...

I simply believe the python authors made the wrong choice.

> That wasn't done, but for reasons that amount to "we don't want to"...

Well, and giant glaring differences in internals. Python3 and python2 have incompatible bytecodes. Swapping compilers on a per-file basis in a language as dynamic as python isn't possible. Python allows dynamic re-writing of modules and source code. How do you decide which version a module is run with if the module is modified at runtime?

If you made all the other changes but still called it Python 2, how would that help anything? You're still making the same breaking changes.

And if you're not talking about making all the same changes...then it doesn't sound like everything else could have been done in Python 2.

Your package build probably never broke because you have an accented character in your name...

I limit all my non-ascii to comments. The tooling just isn't there to support it.

Python2 was not there to support it. Python3 is fine.

Reply on news.ycombinator.com