5 ms·
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. E
by tick_tock_tick 7y ago
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.
- MereInterest 7y agoThat'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.
- dr_zoidberg 7y agoNot just non-US users, but also emojis.
- kissgyorgy 7y agoYour package build probably never broke because you have an accented character in your name...
- tick_tock_tick 7y agoI limit all my non-ascii to comments. The tooling just isn't there to support it.
- kissgyorgy 7y agoPython2 was not there to support it. Python3 is fine.
- ASalazarMX 7y agoI 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 agoImplementation details of u"" could be changed without rototilling the language. Breaking the print statement does not improve unicode support, for example.
- airstrike 7y agoThe 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 agoAll 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 agoIn 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 agoSorry 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 agoBut 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.
- etaioinshrdlu 7y agoI 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.
- joshuamorton 7y ago> 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?
- chc 7y agoIf 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.