Why Is the Migration to Python 3 Taking So Long?

Post by jimbob45 » Fri, Nov 15, 2019, 5:48 AM UTC

Animats wrote: post #48

First off. Python 2.6 and 2.7 supported Unicode just fine. I had a large all-Unicode system in Python 2.6. You had to write u'word" to get a Unicode constant, and use a "unicode(s)" function here and there. Also, the part that remained "compatible" was that "str" remained an array of bytes, even though there was also a type "bytes" and a "bytearray". Early Python 3 was hell for conversion. The syntax was changed for…

Post by c-cube » Fri, Nov 15, 2019, 6:05 AM UTC

josefx wrote: post #215

takeda wrote: post #160

Earlier quoted context omitted.

> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.…

> Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up. Not always. As far as I can tell writing garbage bytes to various APIs works fine unless they explicitly try to handle encoding issues. First time I noticed encoding issues in my code was when writing an xml structure failed on windows, all because of an umlaut in an error message I couldn't care less about.…

Post by takeda » Fri, Nov 15, 2019, 6:13 AM UTC

downerending wrote: post #181

ogre_codes wrote: post #164

Earlier quoted context omitted.

This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.

Note that the question is not "Shall we support Unicode?". Clearly we should. The question is rather whether it would have been better to gradually improve support for it in a Python2-esque way, rather than creating a discontinuity and a raft of new problems, some of which linger to this day. Also, for many purposes, there is wide agreement that ASCII is still the way to go. Even if Americans vanished tomorrow, the m…

Post by flukus » Fri, Nov 15, 2019, 6:15 AM UTC

jnxx wrote: post #133

coldtea wrote: post #69

Earlier quoted context omitted.

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

> On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java... Common Lisp has a backwards compatibility which goes into decades, and implementations like SBCL had no difficulties at all to absorb Unicode. Racket even supports different language standards and completely different languages (such as Scheme and Algol) running on the s…

Post by mixmastamyk » Fri, Nov 15, 2019, 6:28 AM UTC

musicale wrote: post #237

Because they broke backward compatibility in very annoying ways without providing a fallback mechanism. I still haven't forgiven them for killing the print statement, which could have peacefully coexisted with a print() function.