Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

381–390 of 513 posts

Re: Python 2 removed from Debian

#381

Earlier 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…

FWIW, in Linux, this problem does not exist. Everything is UTF-8 and Python 2 would work just fine (and always did). In order to support Windows better, Python 3 introduced support for UCS-4 (or worse, UTF-16) strings (depending on a compilation setting when Python was compiled) and they had to introduce extra string types to distinguish readable strings from binary strings ("bytes"). These extra types made Python 3…

> I just gave up asking encode()/decode() questions at the exams. Very few people understand it, or care enough (and I understand why--it's a ridiculous thing to have).

I get it from the "pass the exam" perspective, since that's one more thing to worry about.

But from my experience in teaching others, doing the conversion between bytes and string implicitly (à la Python 2's way) hinders actual understanding of this very important concept, and it's quite harmful in further study.

Bytes should be considered as a separate, more low-evel thing, away from int/float/strings; at the very least, it should be considered as bits/hex numbers. If you want strings, you explicitly encode/decode them in a way, even if everything is UTF-8.

On top of that, "byte string" is just a confusing concept. It might works for English speaker (by "it's a ridiculous thing to have" I assume you mean that, "'english'.encode() is just b'english', why bother?"), not at all for Chinese speakers, even in UTF-8. There is no b'中文' -- only b'\xe4\xb8\xad\xe6\x96\x87' which has zero meanings in their own.

And even from an easy-to-use perspective: most people don't even work on bytes often nowadays. A more abstract "string" type is all they need, without worrying about how it works under the hood (and if they do, they need to understand how encode/decode works properly anyway).

Re: Python 2 removed from Debian

#382
post #184

Earlier quoted context omitted.

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…

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.

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.

Re: Python 2 removed from Debian

#383

Earlier quoted context omitted.

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 yo…

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`.

Re: Python 2 removed from Debian

#384
post #317

Earlier quoted context omitted.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example. The list of stuff that got…

> and were smug about it I feel like a lot of the people who had this reaction were reacting to being told (correctly) that how they handled strings was broken. A big reason that projects had difficulty upgrading, especially difficulty using the automatic 2->3 upgrade tooling, was because of broken handling of unicode and broken handling of binary strings. I remember reading a quick assessment of a large open-source…

> I feel like a lot of the people who had this reaction were reacting to being told (correctly) that how they handled strings was broken

Can you be very precise about what you mean by "broken" or "incorrect" code?

Re: Python 2 removed from Debian

#385
post #362

Earlier quoted context omitted.

> I think you’re extrapolating unfairly But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users , such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation th…

Tons of other languages have version requirements as part of their end user experience. Whether that’s libc requirements for compiled languages, or Perl language versions being breaking, or even as subtle as differences in behaviour between different compilers such that your system may give different results than another user. So I disagree with your assertion here. Yes it’s unfortunate that this is lifted up to the…

> Tons of other languages have version requirements as part of their end user experience.

That does not dispute the original claim though. It's still a problem for Python even when other languages have the same problem.

> or Perl language versions being breaking

Perl 5.0 code written in 1999 will still happily run in 2023. In part due to the fact that breaking changes are *opt-in* within a Perl script.

Reference: https://www.perl.com/article/announcing-perl-7/

"""Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. [..] Perl 5 still has Perl 5’s extreme backward compatibility behavior, but Perl 7 gets modern practice with minimal historical baggage. """

Honestly, Perl is an example of extreme backwards compatibility that has the user experience at the forefront of their design decisions.

Re: Python 2 removed from Debian

#386
post #346

Earlier quoted context omitted.

Python2 had the 'unicode' class for characters, and the 'str' class for bytes. The whole 2 to 3 debacle was only because somebody thought that naming your string class 'unicode' doesn't sound nice enough or something.

Also the default, what a no-prefix string like "foo" meant changed between the two versions.

Right, essentially the Python developers decided to define a sizable portion of their developer base as "bad people" due to their particular use of the string API and then spent years going to war with them.

The war continues to this day apparently with this Debian news. Somehow you can use fortran77 compilers without people getting angry but you can't use Python2

Re: Python 2 removed from Debian

#387

Earlier quoted context omitted.

It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.

I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.

Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that.

How about one with dataclasses support? Again, you get to install a new interpreter everywhere.

Python packaging continues to be a sore spot for the language.

Re: Python 2 removed from Debian

#388

Earlier quoted context omitted.

Let me be blunt here: Python sucks, but that's at the level of 'programming languages people complain about and programming languages nobody uses'. However the Python libraries absolutely rock and the ease with which you can get really performant number crunching code out of what is nominally an interpreted language is amazing. Statistics, machine learning, engineering, the notebooks etc, I would not pick anything el…

Funny, for about every point I feel the opposite way :-). Python is an elegant language that hits the sweet spot where it is very expressive, and easy to do what you want, and at the same time has enough structure so you don't produce a mess all the time. The libraries are very powerful, but a lot of them are hacks. Numpy and Pandas totally rely on magic and overloading the array indexing operator. You can't express…

NumPy/matplotlib make perfect sense for Matlab users (it's basically a port of Matlab semantics). If Matlab were free and didn't suck so much as a general purpose language, I wonder to what extent Python would have been adopted in scientific computing (Matlab is still pretty strong in some communities, to be fair).

Re: Python 2 removed from Debian

#389
post #362

Earlier quoted context omitted.

> I think you’re extrapolating unfairly But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users , such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation th…

Tons of other languages have version requirements as part of their end user experience. Whether that’s libc requirements for compiled languages, or Perl language versions being breaking, or even as subtle as differences in behaviour between different compilers such that your system may give different results than another user. So I disagree with your assertion here. Yes it’s unfortunate that this is lifted up to the…

I mean, maybe it wasn't quite as clear in 2008, but the Perl 6 fiasco was an obvious disaster that's widely perceived to have killed Perl. It's not a precedent you should want to follow just because it's there.
Post reply on HN