Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

401–410 of 513 posts

Re: Python 2 removed from Debian

#401

Earlier quoted context omitted.

Migrating where there’s a 1-1 mapping of old API to new API is easy, such as the print to print() change. The hard part is when there’s a 1-N mapping, where a single name in the old API becomes multiple names in the new API. These are the most useful changes to make, because they can split apart unrelated concepts that had been erroneously represented by the same object, but require a human to determine which use cas…

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.

It’s not that simple: as the person you’re responding to explained, this was leaky because in simple cases you could pretend those were equivalent but then things would break around interface points when someone introduced things like filenames with Unicode.

I had clean Python 2 codebases which had been Unicode-safe for years and had good test coverage, so porting to Python 3 was trivial and mostly automated. The projects which were hard were the sloppy ones which conflated bytes and Unicode, and the poor development culture which lead to that also tended to mean they had limited testing, orphaned dependencies, monkey patching, etc. which made the migration hard. I also found a fair number of cases where that process fixed other bugs which had been ignored for years.

Re: Python 2 removed from Debian

#402
post #293

I welcome Python3 just fine. Character data no longer being automatically ASCII might be a bit annoying, but it's fine if that's what it takes to support a more global developer base. I just wish they would stop iterating on the minor version so quickly. Why are we on python 3.11 (for workgroups, just kidding)? Is there that much of a difference compared to 3.7? 3.7 even has dicts with stable key insertion order and…

Were strings in Python 2 really only ASCII? I was sure you could put UTF-8 data in Python 2 strings?

Re: Python 2 removed from Debian

#403

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…

The era of "move fast and break things" was disastrous for a lot of things.

12 years is moving fast?

Re: Python 2 removed from Debian

#404
post #58

This really sucks but at least pyenv exists. Basically distros care so little about their users we have to use external tools to use python2. "Everyone has has a chance to migrate" . Doesn't work that way, just yesterday I spent a few hours trying to get scripts that are really good and would take me forever to migrate that are in python2 to work on an ubuntu based distro and this is with pyenv, custom venv,etc... ju…

Your distro exists to provide other people's software. The distro doesn't develop the software themselves. The Python 2 organization has decided to end Python 2. It is completely and decidedly unsupported by anyone as of over two years ago.

If you want to complain about Python 2 being unsupported by the Python foundation, you're free to. But no distro can in good conscience keep distributing a thoroughly unsupported piece of software that's probably full of security bugs.

Regarding the "year of the Linux desktop" thing: Apple is much more aggressive than any Linux distro when it comes to dropping deprecated stuff and forcing their users to move on. Apple hasn't shipped Python 2 for a long time, they ship Python 3.

Re: Python 2 removed from Debian

#405
post #171

Earlier quoted context omitted.

It's not that complicated nor is it a Python specific issue. This is a good article on the topic: https://www.joelonsoftware.com/2003/10/08/the-absolute-minim... A simplistic summary is that you always decode to unicode and always encode to bytes. Another way to think about it is that Unicode is an idealized character model that is reified into a byte encoding, usually UTF-8, for practical usage. It seems to me that…

It’s not that I don’t understand it. The problem is that encode and decode are directional constructs that change depending on context. That’s a poor UI in Python.

Could you elaborate on that?

Isn't it true that encode always means text -> bytes and decode always means bytes -> text?

Re: Python 2 removed from Debian

#406
post #88

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

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.

Re: Python 2 removed from Debian

#407

As someone who does not use Python , the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try to find an alternative. This is because I felt the pain of this transition -- again, as someone who does not program in Python. It has been miserable every time some random utility starts complaining that Python 3 is missing and then somehow when you install…

It sounds like you do use Python, but when you do, you face this problem...

That's fine, but I wanted to clarify - you intend to not use Python, because you have tried and it's not gone well.

Python didn't come out of the woodwork and attack you, so much as you stepped into a (momentarily) troubled ecosystem.

I understand they were dependencies of other projects. By using those, they became your dependencies.

Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed.

Distributions do a decent job distributing modules...

Utilities have an annoying tendency to rely on SomeStableModule==SpecificVersionForNoReason. This compounds the mess, sadly.

Those should be routinely addressed as part of your auditing, along with the whole of the supply chain

I can't really prescribe much... this is just generic advice.

I understand the woes, it's just not as unique as this is painted

Re: Python 2 removed from Debian

#408
post #358

Earlier quoted context omitted.

I edited my comment before you hit post, but I’ll still reply to LOL at that. Think about what you just said for a sec. Then blame that on a python2.

Laughing at your users is a sure path to unlimited success and good fortune as a developer, for sure.

[flagged]

Re: Python 2 removed from Debian

#409
post #395

Earlier quoted context omitted.

> 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: htt…

I’m not trying to dispute whether it’s a problem. I agree it’s a problem. I’m saying that avoiding Python because of it is illogical (to me) because the problems they’re describing aren’t unique to Python, and I don’t think there’s much that doesn’t suffer from it. Perl is an odd one because, as your comment says, Perl is going 5->7 because 6 was such a disastrous break.

> I’m not trying to dispute whether it’s a problem. I agree it’s a problem.

ack

> I’m saying that avoiding Python because of it is illogical (to me) because the problems they’re describing aren’t unique to Python, and I don’t think there’s much that doesn’t suffer from it.

I don't completely agree, but I see your point. Any interpreted language (or non-statically linked binaries) could (and does) suffer from these problems. I'd like to see Python have a better packaging story...but for now we live with shipping the developers environment (via docker or virtualenv) for running complex Python applications and services.

I will say that *statically linked* compiled languages are able to avoid many of these problems because running these binaries typically only requires the OS (eg, Go, Nim, Rust, Zig, C/C++ when statically linked, Object-Pascal, etc)

> Perl is going 5->7 because 6 was such a disastrous break.

Agree. And they did the right thing by actually renaming it Raku and skipping the version release.

Re: Python 2 removed from Debian

#410
post #231

I really feel like the community was a difficult pain in the ass during the 2->3 migration. There were breaking changes but I’m sure the Python maintainers didn’t expect the community to react so badly. Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.

Guido has done some pycon keynotes in the recent past and said himself he takes some of the blame for the transition. He says he greatly underestimated the impact of breaking changes and the inertia to get the community to change code. In particular not shipping tools to help automate the migration, or even thinking through a migration path with targeted backwards compatibility/back ports from the start (these eventu…

I think both of you are looking at some of the same problems from different angles, and there are some interesting ways in which the community shifted over the same time period. I suspect some of Guido’s instincts were guided by the earlier community which was more early-adopters, and simply younger. The 1 to 2 migration was easier because the median developer was far more motivated to switch - you weren’t using it if you weren’t a fan.

Python’s rise brought tensions there in multiple ways - business users started wanting longer-term support and tools for migrating large code bases, but relatively few would pay for them, and some maintainers had either drifted away or retired, or simply had less time available due to things like starting families or getting promoted. The 2 to 3 migration really highlighted the gap between commercial open source and hobbyist projects, and I’m sure now anyone would fundraise for support having seen how that worked out.

The other thing we’ve been seeing is a switch to faster releases industry wide and I think that showed some serious tech debt. Projects which have CI & decent tests had a much easier time shipping updates or having two release series for an while, and the 2 to 3 migration really highlighted that. Some of the griping was really showing that older projects often had the frictional disincentive of that tool. That’s still relevant because of the way security issues are forcing more frequent updates now.

Post reply on HN