Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

391–400 of 513 posts

Re: Python 2 removed from Debian

#391

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 python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. The other side of that coin is that the python maintainers went out of their way to push back the Python 2 EOL. They kept on pushing the date back and back again, as per the sunset page: "We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Py…

> I have no time for whinging snowflakes complaining 12 years (2020-2008) was not enough time to migrate their code to Python 3. Hell, even the original 7 years (2015-2008) should have been long enough for 99.999999% of the community.

I'm old enough to have read this when it came out...and it changed my view on backwards compatability (from Joel Spolsky of Trello, FogBugz, and StackOverflow fame)

"Code doesn't rust": https://www.joelonsoftware.com/2000/04/06/things-you-should-...

If a company has production Python2 application / service (with hundreds of thousands of LOC), what business value does it bring to migrate it to Python3?

At that point, if you've got to make severe changes, folks might decide to use a language that doesn't impose breaking changes (and business cost) on them. YMMV.

Re: Python 2 removed from Debian

#392

Earlier quoted context omitted.

What is a "codemod"?

A codemod is an automated refactor. Codemods are typically done by writing scripts that manipulate the AST of code in files or by writing a regex to find and replace. The name originates from an internal script at Facebook called codemod. It had a public open source fork if you are curious. https://github.com/facebookarchive/codemod

Thanks for the explanation!

Re: Python 2 removed from Debian

#393
post #362

Earlier quoted context omitted.

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.

I pointed to Perl specifically because it’s another contemporary to Python in terms of OS scripting while having had a much harder break.

Re: Python 2 removed from Debian

#394

Earlier quoted context omitted.

That's the dream of containers. Arguably this is the "reality" of Nix. But the reality of containers is that if a layer gets invalidated, you need to refetch packages that are lower down. If the Python 2 versions (or Python 2 itself) is removed, then you can't "just" surgically make the change you want in the container without affecting the rest of the system (this is a major failing of Docker, but the world we live…

How would Python 2 end up removed from a container image?

If someone builds a container that is designed like this:

  FROM debian

  RUN do-x
  RUN install python2
and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.

Re: Python 2 removed from Debian

#395
post #362

Earlier quoted context omitted.

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

Re: Python 2 removed from Debian

#396

Earlier quoted context omitted.

The difference is that Perl 6/Raku was a huge change from Perl 5. For Python, the small improvements weren't worth the break in compatibility.

You underestimate how big of a change Python 3 actually was . Changing how strings and bytes are handled has a huge blast radius. It broke almost every library or application I worked on. Everything else was peanuts to that semantic change. It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly. A…

Python 3 had a HUGE impact on existing code, yes. Everything broke. But Python 3 didn't actually change much for the people writing new Python code, it just broke the old code.

Raku is a completely different language from Perl. Writing Raku instead of Perl 5 is like writing Rust instead of C++.

Re: Python 2 removed from Debian

#397

Earlier quoted context omitted.

> This is totally false - code produced by 2to3 no longer ran on 2. That's what "breaking changes" and "backwards incompatible" means. What exactly is hard to grasp? > So you ended up w a chicken and egg problem. You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job. Python2 has been on the path to deprecat…

“It's high time people like you stop making up excuses and start to own up their misconceptions, misjudgements, and mistakes.” What is it about python 3 that brings out this lecture stuff. I would really like to see the inside of this “easy” change at even the bigger most well resourced places. Google / Facebook / Dropbox etc. At small places where a program is working and programmer is gone they are not investing in…

>What is it about python 3 that brings out this lecture stuff.

I think some people convinced themselves that using "" without the u"" was disenfranchising to people who don't want to use ASCII to represent their language. This transformed a practical argument over syntax into a moral crusade.

Re: Python 2 removed from Debian

#398
post #358

Earlier quoted context omitted.

It’s like my grandma complaining about the internet being slow... because her CPAP machine is tethered to the clinic with an IP connection and is shutting down every night at 2 AM because a Python script on the server at the other end is no longer running.

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.

Re: Python 2 removed from Debian

#399
post #122

Earlier quoted context omitted.

I see people saying that the migration was painful, but my own experience with two separate Python 2->3 migrations were so smooth they might as well have been a minor version bumps. I don't know where this discrepancy comes from.

It comes from all of the people who don't actually use Python and just poo on it from the side.

Or all the people maintaining large python in house projects that had a certain expectation of how many people it takes to maintain a mature largely finished project which is suddenly much higher. I supported our framework adding a feature here and there, on boarding a new app team here and there for like 10% of my time. To switch it all to Python 3 would have been major work, high risk, and no real benefit. We either still run Python 2 now, or have migrated to Go (slightly more verbose code and slightly slower dev time, for much lower compute foot print).

To be fair it was a place where the Python fans advocated for its use but to management was always a bit skeptical, so we had to make it all seem easy. We had good solutions to internationalization which all broke with Python 3.

Re: Python 2 removed from Debian

#400

2to3 really showed that Python didn't understand their audience. If they had started a new project called COBRA and just eventually had it over take python the world would be all over it. But massive breaking changes going from 2 to 3 was a disaster for their audience. Worse still you could hear the acrimony in Pythons communications on the topic.

Well, trying to sell a project to the higher-ups is a lot easier when you can say > Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3" Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: > Hey, there is a new interpreter out there called COBRA. We need to rewrite our who…

Except they say, Python versions are a risk, all non Java projects are forbidden.
Post reply on HN