KILL IT WITH FIRE
Yes, Kill PYTHON3 with Fire, end this stupid unicode fetish!
Python 2 removed from Debian
211–220 of 513 posts
Re: Python 2 removed from Debian
#212Earlier quoted context omitted.
> "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…
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?
Re: Python 2 removed from Debian
#213Earlier quoted context omitted.
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.
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 so…
> 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.
Re: Python 2 removed from Debian
#214Reminder that python 2 was liked once.
Re: Python 2 removed from Debian
#215I can't use Linux as a daily driver because of the Python 2/3 breaking change. My personal wiki (WikidPad) just doesn't work properly under linux due to the changes that happened in Python and then wxWindows. There are ports that barely work, but all the dialog boxes to adjust anything just error out.
It's really sad that the Python folks committed suicide this way, all over a unicode fetish.
Re: Python 2 removed from Debian
#216Earlier quoted context omitted.
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…
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.
Re: Python 2 removed from Debian
#217Earlier quoted context omitted.
> "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…
> 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 m…
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.
Re: Python 2 removed from Debian
#218Earlier quoted context omitted.
Yeah, coming from C#, Python 2's unicode support was so bad I almost abandoned it immediately as a Chinese speaker (and to make it worse, I use Windows). You literally can't use IDLE for learning/testing properly half of time due to encoding issues. And what surprised me most is that every time I mentioned this, there would be lots people telling me how this is a superior design because you can operate string like by…
We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still…
The biggest danger in Python 2's unicode handling is that incorrect things somewhat worked (until you got a non-ascii character at which point it exploded or produced incorrect behaviour).
I'm sure you could do things well in Python 2 with proper combinations of encode/decode, but it wasn't obvious where you even needed those because with ascii text, things "just worked" transparently. With Python 3 it's very obvious where you need encoding/decoding because bytes != str.
Re: Python 2 removed from Debian
#219Earlier quoted context omitted.
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 so…
> 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.
Re: Python 2 removed from Debian
#220Earlier quoted context omitted.
Yeah, coming from C#, Python 2's unicode support was so bad I almost abandoned it immediately as a Chinese speaker (and to make it worse, I use Windows). You literally can't use IDLE for learning/testing properly half of time due to encoding issues. And what surprised me most is that every time I mentioned this, there would be lots people telling me how this is a superior design because you can operate string like by…
We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still…
> That was a decade ago, to finding that the "python" command still launches a Python 2.7 interpreter in 2023 is just beyond belief.
The problem is not the end-user invoking the command.
The problem is scrips expecting `#!/usr/bin/env python` to invoke python-2.