Hacker News Reader

Comment by tgsovlerkhgsel | Hacker News Reader

Glad this is finally mostly over, but... that was bad. I wonder if the energy that had to be put into this migration by everyone involved was worth what seems to be relatively small improvements.

The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is), and the new string types make code more verbose, and the way they were handled introduced countless hard to find bugs during the migration.

View on HN

IMO you're oversimplifying things without appreciating the scope of what went into Python 3.

Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013):

https://www.youtube.com/watch?v=f_6vDi7ywuA

> "Python 3.3: Trust Me, It's Better than 2.7"

The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing.

Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then maybe it would have been. As it stands, Python's biggest weaknesses remain unaddressed.

> The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing.

That's reading far too much into a tongue in cheek presentation title.

Besides, good devs are typically reasonably skeptical of new and shiny.

And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upgrade, so damn straight you'd need convincing to make the investment.

Hell, look at how many Java codebases are still 1.8 because of the upgrade cost of going past that, even though modern Java has many compelling features.

And expecting Python 3 to remove the GIL is incredibly unrealistic. How much Python code in the wild implicitly depends on the behaviour of the GIL? All of it.

> How much Python code in the wild implicitly depends on the behaviour of the GIL?

About as much as depended on Python 2-specific features?

Sure, but the GIL behaviour is inherent to all concurrent (for a given value of concurrent) Python code. And code that could be run concurrently.

Removing the GIL would be bloody fantastic, but it's far more involved than 2 to 3.

A lot of codebases could be converted from Python 2 to Python 3 with just some fairly mechanical work and light refactoring on top. GIL would be a thing of a completely different magnitude.

It’s so trivial! All that needs to happen is someone else putting in the work. And for free, please!

2to3 was always available to do that work, for free, yes.

OCaml 5 recently solved the global lock problem by introducing concurrent domains in which one or more threads share a lock. So old code keeps spawning threads with a shared lock, but new code can work with single-thread domains and manage in which domains does old code run.

Python 3 paved the path for the changes that you mentioned you wished for, some of which are being tackled now. It's not only about what Python 3 offered at the time, but also about what it made possible in the long run.

How does print-as-function help anyone remove the GIL?

Damn, get over it. Who cares that print is a function now?

While that specific example is stupid the general question is very valid. I can't see what paved the way. The most invasive change was the unicode one and even that seems irrelevant to eg the GIL.

simpler code is always important to pave the way for innovation

>The fact that such a talk exists shows that the improvements aren't worth the switch for most users.

More like it shows that many people like GP are only aware of the superficial changes.

That's a bit cynical since I think if we were still dealing with the issues python 3 fixed today, I'd be very disappointed in python overall.

And, the latest iterations of Python3 have real usability improvements - the error message improvements alone make development a lot nicer. And the perf improvements and jit coming I think in 3.13 will really make more people consider py3 for their new projects.

> No, it's not even remotely worth the amount of confusion and work it caused.

Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of my time debugging straightforward code was spent chasing down and fixing UnicodeErrors, knowing that some will still remain. And that includes code that used nothing but the standard library.

Now you might think that’s not important, and though I disagree (especially when talking about “most users”) that would be fair. But it is a substantial improvement going from 2 to 3.

There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years.

The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example.

The fact that they removed syntax for Python 3 meant that all kinds of scientific computing code had to be transitioned even if it didn't use any strings!

Wait, if it didn't use any strings, then it didn't use the print statement either, right?

For printing it's not a problem because a string containing unicode will be transparently printed in both Python 2 and 3 (at least on Linux/Mac, not sure how Windows deals with it).

It's also not a problem if you only have ASCII strings.

The print function was the simplest part of the transition. For one you could find and replace all instances of it fairly safely across your codebase and you could quickly discover any places where things broke because of a bad replace. That part took like an hour for a large codebase.

The Unicode handling on the other hand took ages because string handling is not easily searchable and replacing it requires understanding what the piece of code actually does.

So you have it exactly backwards: if the only migration was the print function then it would be a quick and relatively painless process. But fixing the hard thing which was the broken str/byte model was the hard transition.

I am curious if you actually went through this transition or if your opinion on this is more based on observation of others’ work.

Python is a scripting language. Imagine if bash suddenly changed its syntax so that that instead of printing using echo, you now have to write echo(). Sure it’s just a pair of parentheses. But you probably have thousands of shell scripts on your computer. Are you really going to get your hands dirty and risk editing them without knowing what they do?

Of course not, you’re just going to revert back to the version of bash that doesn’t require parentheses and sit on it for as long as you possibly can.

Code exists in three states: actively maintained, done/mature, and obsolete.

Python 3 attacked mature code, forcing developers to either go back into active maintenance or to obsolete it early.

I did transition some Python 2 code to 3. But mostly it was uneconomical and risky, so the vast majority of it sat on Python 2.7 until it was no longer needed.

I feel that most of the people who had a positive experience with Python 3 were people doing webdev using Django. They were working on monolithic actively maintained projects and so transitioning to v3 was just a normal maintenance activity.

You are correct that my experience is mostly though not exclusively we Django projects. I guess maintaining your code pays off in the long run.

Again, you are arguing that running 2to3 and testing your code was hard. I guess that may be true. But having hunted for a ton of subtle Unicode bugs that problem was very worth fixing.

> There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years.

Didn't the unicode changes go on until at least Python 3.6? The issue that most C APIs did not care about their byte strings having any encoding at all seemed to cause one headache after another, especially on Posix, where everything touching the operating system could return random bytes. Reducing the scope to unicode wouldn't have sped up the transition one iota.

Not the one you replied to, but we were doing things mostly without strings (audio processing, stuff with bits) and python 2 worked perfectly fine. We had started this project as late as 2013 because the important libraries had not been ported yet and when the stuff wrapped up in 2017... I'm not sure if we could have switched by then.

So personally I'm ok with Python 3 but I actually never ran into the described problems despite using Python 2 for years, so it was at least not a universal problem that needed to be solved in such a breaking way.

So not a single Cyrillic path in your INI or CSV files, or in the user input (CP_ANSI) to be printed onto the Windows console (CP_OEM, unless you’re in IDLE or redirecting the output, in which case CP_ANSI)? (The standard library’s CSV module was particularly atrocious at Unicode as I remember.) Not a single Chinese comment in your hardware descriptions? I envy you, but that’s a still a very specific corner of the world.

We were working exclusively with filenames (and files) that we generated ourselves, moving them around in our own infrastructure, and writing all of our own configs, yes :P

I didn't insinuate that there weren't problems or that I wanted to keep Python 2 - just that it was perfectly normal to use it and not run into problems. I think I only remember a handful of encoding problems with my other python 2 adventures...

Look, the breaking change to python3 was a disaster.

There’s no need to sugar coat it.

It was incompetently managed, in a way that made the technical success of the work look like a failure.

That’s on them. They screwed up.

I lived through it; I feel no particular need to smile and nod and say “it wasn’t that bad”. It was bad.

Things are good now! Python 3 is great, it’s well supported and the people involved all learnt a lot about how important managing communities is, as well as writing good code.

So, all round, a success!

…but, if you don’t acknowledge failures in the past, you’re doomed to repeat them.

> Now you might think that’s not important

I don’t think your experience with Python 2 is not important; I had similar issues with it.

No one is seriously going back to Python 2 at this point.

However, the process is a lesson worth studying; and the take away is not “what a technical success!”

… it is: never do this.

Big scary breaking migrations are bad, they hurt your community, and leave bitterness behind them.

Even if the result is better, technically; there are other factors that need to be considered too.

> No one is seriously going back to Python 2 at this point.

No, the community is stupid and wrong. My machine learning professor (actual professor, not a teaching assistant) only used Python 2 in 2017. Imagine how many people had their opinions shaped by someone like them.

> … it is: never do this.

By that standard, we would never get things like angular 2 or Raku.

Would it be better if we renamed Python 3 to some other name and pretended it was a completely new language?

IMO Angular 2 was a huge fail in usability. Angular 1 was a joy to use and 2 was a disaster in terms of writing code in it.

However, I am firmly in the Python 3 camp. It is a better language (all the newfangled bullshit notwithstanding).

> Would it be better if we renamed Python 3 to some other name and pretended it was a completely new language?

Quite possibly yes? It doesn't run python2 code, it can't be inter-linked with python2 code, so is it really the same language? The hybrid dialect that works in both does exist but you have to have compatibility shims in a few places.

By comparison, most C compilers will let you use C89 and C17 code in the same project provided you set the compiler options, and C# provided the "netstandard" target for libraries to smooth the transition between Framework and Core runtimes.

> No, the community is wrong.

Sometimes.

I mean, Russ basically said that about all the work people were doing on the golang package manager and did his own thing, and it worked out. Good job! Sometimes, a smart person can do something that is better when they're deeply steeped in the domain.

> No, the community is stupid.

I personally find that most communities have a lot of very clever, very thoughtful people in them, and if you listen, you can learn a lot from them.

Just because they don't agree with you, doesn't make them stupid.

I think that its basic respect to listen to your community, acknowledge them and think about what they say, even if you go your own way.

...but, if you (as a maintainer) just think they (your community of users) are just a bunch of idiots, do whatever you like. They are idiots if they hang around in a community like that.

Agreed. Unicode change alone would be sufficient do to Python 3.

Yes, I have and it was simple but with plenty of footguns for developers who had not groked how you were supposed to work with strings. I am happy we moved away from that but I am not happy with the solution Python 3 picked. I think e.g. Ruby 1.9 came up with a nicer solution to the problem and one which broke much less code.

Python 2 strings pretty much just worked with UTF-8, didn't it? Or did they manage to make Python 2's string handling worse than C's?

Uh, Python 2 was aboslutely fine at working with non-ASCII text as long as the only operations you try to do on it are "take the length" and "reproduce a string verbatim". Notably, it did not forcibly explode when encountering a character appearing in a comment or string literal or whatever that couldn't be interpreted as utf-8. This was a real step back for code that, oh, say, used filesystem interfaces to look at untrusted filenames.

Not if “reproduce the [possibly Unicode] string verbatim” includes concatenating it with others in order to insert it into some sort of context, that will absolutely blow up if you’re not careful and unfortunate input data comes in (I hope that happens before the code enters production!).

For comments and string literals in Python code, note that Python 3 changed the default from Latin-1 to UTF-8, but you can still use -*- coding: -*- to change that. Bytes literals outside of ASCII range you’ll still have to escape. As for program input that’s possibly invalid UTF-8 but not in places you care about, you’ll need to set errors='surrogateescape' or similar explicitly (or possibly set an 8-bit encoding like Latin-1, though not if there’s a chance of UTF-8 in places you do care about).

Paths are a bit painful, yes, both because there’s nothing on Unix systems that precludes /home/alice having filenames in UTF-8 and /home/boris in KOI8-R, and because NT paths are not byte sequences at all (they are WCHAR, that is 16-byte-number, sequences, in no way required to be representable in the current CP_ANSI). Having uninterpreted byte sequences as filenames would work to solve the former issue, and it does: I think most functions in os will accept bytes paths as input and treat that as a signal that you want bytes paths as output (if any). For the latter the cleanest solution is probably an abstract Path type—and you get one, in the standard library’s pathlib. That didn’t work all that well in early Python 3 versions, but it does now. (And IIUC inspired Rust’s abstract-type solution to the problem.)

This is true, almost all "string" operations require you to know extra information about the string's "type"—which, yes, includes its encoding.

Python 3 takes this fact and runs with the stance that strings should, by default, carry their encoding with them (and that encoding is specifically, more or less, a sequence of quasi-Unicode code points with unspecified internal representation). But this is an intensely half-baked solution to the wrong problem, because you need to know much more about a string than its encoding for just about any string operation you'd want to do. Just with Unicode code point concatenation, you can run into plenty of trouble with: - strings containing control characters - strings with unpaired surrogates (which okay, shouldn't really be there, but get used for various reasons anyway) - strings containing combining characters - strings in different natural languages - strings in languages with ligatures - strings with ligature-like emoji (and this is obviously not remotely close to exhaustive.)

I think the issue here is that Python 3.3 was more like 3.0-dev-rc3

The first python 3 versions were not great and were missing some things. I think 3.3 didn't even had pip builtin

Would you still feel that way if Python had a series of upgrade versions that "hand-held" the migration and giving warnings about behavior that was going to break?

I ask, because I know I would have wanted that.

This talks title probably comes from the awful python 3.0+ versions. 3.0 was so bad, they had to fix and revive certain in the later versions. IIRC 3.3 was the first version who was considered decently enough, that someone you could use it for more serious things.

I bet that you did not watch the presentation.

Also, the fact that there is a talk with such a name does not mean anything other than that someone is out there trying to clarify what the transition is about.

(There could have been a video "Windows 7: Trust me, it's better than Windows XP" and you probably still would say that it showed that improvements aren't worth the switch for most users.)

Unless I'm missing something what in here supposed to justify a decade of pain? Hell most of it could have been easily done in python 2 and slowly via warning and errors transition codebases.

The changes Python made was made in Perl without breaking compatibility, you just wrote say

    use v5.24

in header to use given feature set (defaulted to something old to not break old stuff)

The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl.

At the very least they should've just made new one be under .py3 and just make Python3 interpreter transpile Py2 code at runtime

Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.

No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts.

The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.

For sure. I'd argue it was debatable to even "normalizing" all the built in packages to be consistent.

I think very few people had trouble remembering them, and if you're using one, you'll be looking up documentation for anything with more than a few methods.

It really is frustrating in these situations with high level languages. It's super possible to do the majority of changes they did in non breaking ways.

Hell, they do it already with the __future__ package. Where did all that compatibility work go in python3?

> No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts.

There was some breakage between 5.6, 5.8, and 5.10; Unicode is hard, and it takes time to get it right. But I think the key difference I've heard as a mostly python avoider is the intent was for code written for 5.6 to probably work in 5.8 and 5.10 and if it doesn't, for there to be a way to have one file that works for all versions.

From what I understand, it's not easy to have a python module/script that works in 2 and 3, and you can't go to 3 unless your dependencies do, so if you have a lot of dependencies (as is modern), you're stuck on 2. Your dependencies won't want to move to 3 either, because their users are stuck on 2, so if they just switch to 3, they're droping users; instead they need to support two parallel versions of their code. Most perl modules didn't have to do anything special to support 5.6 and 5.8, but if they did, it was usually small and it could be done within the file with conditional compilation --- I don't think that was an option for python.

> You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code

.. but you can't use old libraries in new code.

Just to clarify, in Perl you can have your main code be in Perl 6 (or whatever), and then "import" and use libraries that "use v5.26"?

No, Perl 6 is a completely different language (now called Raku, because otherwise it sounds like a newer version of Perl 5, and never intended to be compatible with Perl 5). But because of the Perl 6 situation, even a change the size of the Python 2 to 3 change would be a "Perl 5" version update.

I think having Python 2 vs. 3 is a clearer demarcation, myself, but the Perl community cares a LOT about backwards compatibility.

The people working on Perl still support running in old mode. You can grab the latest Perl 5 release and run old-style Perl code in it. The people behind Python don't support Python 2.

Just because the old way was deprecated doesn't mean that it wasn't possible to run old and new code next to each other.

Also, Perl 5 is a very different example. While I haven't followed Perl for quite a while, ISTR that Perl had a very similar transition from 4->5 (I personally remember spending a lot of time trying to get old code working on newer OSes). Also, AFAIK but I may be wrong, Perl 6 has not really taken off like Python 3 did.

Yes; and now we have to keep every version of Perl around in our package managers because they're all used by some code.

That's terrible practice.

That means the piece of software will work also in the future.

Personally I only use python for throwaway scripts. Whatever is written in Python likely won’t work in 10 years anymore. So they’re all lost in time. Whereas I can continue some of my C++ eternity projects and they still work perfectly fine.

You don't. The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code.

If you don't write special in your code, Perl doesn't have a "say" method (because it didn't have one in Perl 5.8). If you declare in the code that you're code for Perl 5.10, magically there are all the Perl 5.10 features, including "say". You can also declare you want specific features, rather than declare a specific Perl version.

  $ perl -v | head -2 | tail -1
  This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-cygwin-threads-multi
  $ perl -e 'say 1'
  Number found where operator expected at -e line 1, near "say 1"
          (Do you need to predeclare say?)
  syntax error at -e line 1, near "say 1"
  Execution of -e aborted due to compilation errors.
  $ perl -e 'use 5.010; say 1'
  1
  $ perl -e 'use feature "say"; say 1'
  1

The best thing about this is you can mix and match libraries from earlier and newer Perl versions. If a library says they want Perl 5.10, they get Perl 5.10, even if you want both Perl 5.30 and that library.

If only Python were as reliable for backwards compatibility.

The Perl community is going through their own Py2->3 moment, and they're doing it with great care. They're going to create Perl 7, which will be Perl 5 where the "defaults" make the language look more like Perl 5.32 rather than Perl 5.8 [1]. Modern Perl scripts don't need so much boilerplate to enable modern features. They know exactly the trouble this will cause; if Perl 7 ever becomes the default Perl interpreter, the only one, it _will not run_ lots of very old Perl scripts untouched, because the defaults will make years worth of language changes suddenly visible to those scripts. Even if the fix is just to slap "use 5.008" on every script, they worry about it. That's a much better attitude than the Python developers.

[1] https://www.perl.com/article/announcing-perl-7/

> The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code

> That's a much better attitude than the Python developers.

You do realize that this comes at a cost, right?

A lot of decisions in Python3 (and further) are based on the desire to keep the interpreter simple.

Python Core Team doesn't have unlimited resources, and even if they did, the cost of complexity grows non-linearly.

py2 -> py3 transition did not go as planned, but that doesn't mean that following Perl route would have had better outcomes.

The removal of implicit conversion between bytes and strings via ascii did not introduce bugs, it showed were you already had bugs that you maybe did not yet notice.

That's only true if you ever received Unicode input. There are plenty of uses of strings that never do - enums, DNS domain names, URLs, HTTP parsing, email addresses (from any sane provider) etc.

I mean...

https://www.w3.org/International/articles/idn-and-iri/

https://www.rfc-editor.org/rfc/rfc6531

etc...

Just because you can get away with ignoring the non english speaking world doesn't mean Python should pretend it can.

You can't use Unicode characters in HTTP messages - IDNs and IRIs are encoded into ASCII before being sent on the wire (using punycode for IDNs and percent encoding for IRIs).

As for RFC6531, my understanding is that virtually no email provider implements it, because of the same risks that make browsers often show IDNs as their punycode version - Unicode is extremely easy to use to confuse people maliciously or accidentally, since it contains vast amounts of duplicate characters (e.g. Latin a and Cyrillic а), even larger amounts of similar looking characters (e.g. Latin r and Cyrillic г), and even characters that are ambiguous unless you choose a locale! (the CJK problem, where the same Unicode codepoint can represent different characters based on the locale - whose locale to use when communicating between two machines being the implementer's problem).

Also, I'm not saying that Python shouldn't have had proper suport for separating byte arrays from encoded strings. I was only pointing out that there were actual legitimate use cases where a valid Python2 program was broken by the Python 3 Unicode string transition, whereas the GP was claiming the Python 2 had to have been buggy already.

Edit:reading around more, it seems that RFC6531 is getting some traction, and many providers accept sending to/receiving from internationalized emails even if they don't themselves allow you to have a Unicode email (e.g. you can't have айа@gmail.com, but you can correspond with someone having such an email at a different provider). So, email was a bad example in my list. The rest still stand.

No doubt some things broke "needlessly", or that things couldn't have been done better, but I don't see how it could have been avoided since there is no way to distinguish between "I know that this string will always be ASCII" vs. "this string can contain non-ASCII".

For example, what if I want to enter "ουτοπία.δπθ.gr" in an application, via direct user input, a config file, or something else? Or display that to the user from punycode? No one expects users to convert that manually to "xn--kxae4bafwg.xn--pxaix.gr", and no one will understand that when being displayed, so any generic IDN/domain name library will have to deal with non-ASCII character sets.

The same holds true for email addresses: "ουτοπία <a@example.com>" is an email address. Sure, this may get encoded as "=?UTF-8?q?…?=" in the email header (not always, "bare" UTF-8 is becoming more common) but you still want to display that, accept it as user input, etc. People sometimes to forget that the name part of an email address is widely used and that any serious email system will have to deal with it, and non-ASCII input has been common there for a long time.

In specific applications you can often "get away" by ignoring non-ASCII input because you sometimes don't need it. For example I'm working on some domain name code right now which can because everything is guaranteed to be ASCII or "punycode ASCII", so it's all good. But in generic libraries – such as those in Python's stdlib – that's much harder.

In Germany, there are two competing flight comparison engines with very similar names: fluege.de and flüge.de.

How would you send an email to the customer support of flüge.de? How would you parse that domain?

IDN is here, and it's here to stay.

Strings are still strings in Python 3; if you do 'foo' == EnumValue then that will work fine in Python 2 and 3. If 'foo' is from an unknown source: yeah, you might get a bytes type in Python 3 and an error, but that's the entire point. Turns out that in practice, it can contain >0xff more often than you'd think.

Certainly today DNS domain names, URLs, and email addresses can – and do – contain >0xff input, and for some of these that was the case in 2008 as well (URLs and email addresses – IDN didn't come until a bit later).

The Python 2 situation was untenable and lead to a great many bugs; "decode errors" were something I regularly encountered in Python programs as a user. In hindsight, the migration effort for existing codebases was understated and things could have been done better with greater attention to compatibility, but the problem it addressed was very real.

> DNS domain names, URLs, and email addresses can – and do – contain >0xff input

Is that true? My understanding is that DNS never supported non-ASCII and so punycode was invented.

I mean, in the most basic sense you could always have non-ASCII chars in your filenames on a webserver, which could be part of a URL then.

DNS-the-protocol still doesn't support non-ASCII input, but DNS-as-people-use-it does. I expanded on that in another comment I just posted, so I won't repeat it here: https://news.ycombinator.com/item?id=34230218

But is also very rare that you ask directly for domain name resolution in the first place; you are usually instead using something directly or indirectly that happens to be remote, and that eventually happens to have a punycode encoded non-ascii hostname or top level domain. But there's no garantee that you (or the libraries, or the libraries that your libraries use...) are only handling the ascii punycode.

I can count on my fingers the number of places I invoked manual DNS lookups inside production code.

I've seen way too many cases (possibly resulting from 2to3 autoconversion) where the code ran without errors, you just couldn't log in because the xsrf token was "b'123456'" instead of "123456".

Even a decade ago, you would have needed to support Unicode if you handled any of those strings. IDN domain names existed as far back as 2003, so unless you could guarantee that everything was in A-label form already, you would need to worry about that (which affects URLs and email addresses as well). URL paths might be Unicode if no one normalized it to percent-encoding first. And HTTP headers--like email headers--could well be non-ASCII despite the standard prohibiting unencoded non-ASCII text because the real world is full of shitty implementations that don't follow standards, and the internet community generally runs on the principle that it's better to force everybody else to try to make sense of the result than tell those people to fix their code.

Indeed, I just had to port some code that had been running happily for years at the south pole to py3 (due to EL8 upgrade and not wanting to install the py2 world). It was something talking to a HV supply over a serial port which of course only spits out bytes, but then needed to parse using string handling. It wasn't that hard to port but it took a few tries to find all the places necessary, requiring debugging over a rather slow ssh connection (that is only up when the satellite is up).

For speakers of languages that cannot be written in ASCII-only, the importance of the improved unicode handling really cannot be overstated, especially for people new to programming.

Absolutely. Frankly, it's 2022. Putting some useful subset of unicode in is mostly a solved problem.

At least python3 got that right, unicode by default.

Heh, I still regularly write workarounds to deal with the Python 3 transition. These days, the main cause of problems is the disagreement of what the python 3 shebang is. A lot of especially Google code "supports" Python 3, but expects `#!/usr/bin/env python` to work. That means messing with environment variables and files so that `python` is available as a wrapper script which just executes `python3`.

I don't understand why there apparently wasn't a clearly stated preference about `python` being Python 2 and `python3` being Python 3 from the Python org.

strings, bytes, utf-8 and more have continued to stymie me while converting code over.

Honestly curious if it would have possible to make it better/faster.

i think it’s clear this was a huge mistake. none of these changes were critical to pythons current success. python stalled for 10 years if not more because of these non-BC changes. it will fragmented indefinitely. this is a good case study of how one big ego can completely derail a massive project for decades

It won't be fragmented indefinitely, that claim might've carried some weight five years ago, but these days I see very few Python libraries that still support Python 2.7. And, if they do, it strongly implies that they've not been maintained for some time. (See also, a dependency on six) - with the caveat that sometimes you don't need to continually upgrade a library that fills its desired niche perfectly.

Hell, if you're still using 3.6 you're limited in your ability to upgrade dependencies, 3.8 is generally the minimum supported Python version these days.

The people it lost are going to things other than python3.

Yeah, I mean personally the only thing that would keep me in the community is wxPython, which AFAIK still only supports Py2.

The last wxPython release that even supported py27 was from close to three years ago, and you would have known if you spent half a minute looking into it before making an absurd claim.

> Assume good faith.

I tried using the library less than a year ago. I must have missed something. This would be great news… if the way you told me didn’t make me feel like shit.

Not disagreeing.

Is that true? I have little data, but I'd imagine most are just working on small/mid size scripts that can be upgraded easily. There's really not many big projects your average joe will be coding in python, from what I've seen.

Where would they go from python? Node?

Even if that's true, it's extremely obvious that Python is the language of choice for some very hot subfields at the moment—things like ML, computer vision, etc.

It may have lost a lot of people who got frustrated by the 2->3 transition, but Python is clearly not in a bad place as a language today.

Python is still fragmented 12 years on. It might eventually get fixed, but it still isn't.

Most actively maintained Python code works with Python 3 now, but there's still a whole lot of even maintained code which uses `#!/usr/bin/env python`.

Can you explain how exactly Python stalled as a result?

A lot of devs were busy with the busywork of migration rather than improving their libraries. For a long while you often got stuck between one critical library that has no alternative only supporting 2, with a second critical library for some other thing that also has no alternative only supporting 3. So doing your project in Python wasn't feasible.

Reply on news.ycombinator.com