Hacker News Reader

Comment by mjw1007 | Hacker News Reader

Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support.

I doubt anyone is checking for potential security problems in the Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that.

It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran.

In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.

View on HN

What? This isn't about "languages". It's about software!

Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repository. Starting very soon - Python 2 will have an entire set of unmaintained runtime and libraries in the package repository. You know - actual, offically, unmaintained software! Unmaintained software that other packages, including Calibre in this example, further build on. Of course they're throwing this out.

If you're concerned about language support there are multiple solutions like:

* Port your stuff to Python 3 and enjoy first class support

* Running Debian Buster

* Running CentOS 8, which will probably profit from RHEL 8's Python 2 support-with-an-asterisk until 2029 [1].

* Installing it manually on your system

* Installing it manually in a container

This is how it feels to run legacy software - it's bloody inconvenient. But that's not a problem Debian needs to solve for anyone.

[1]: https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

Python 2 is only unmaintained because the Python foundation is refusing to let anyone "officially" take over support. There are thousands of programs in Debian with less core developers than Python 2 working just fine.

It's understandable that the PSF wouldn't endorse a maintainer.

They can't stop someone from releasing something that runs just like Python 2 and has a different name.

That's true, but it might make packaging tricky -- lots of the old Python 2 software people want to run will have '#!/usr/bin/env python' hard-wired in, and having to fix those would be annoying.

You'd have to fix those lines anyway, since /usr/bin/env python will be pointing to python3 executable in the new releases, not python2.

It's been that way on Arch Linux for years, but I wouldn't expect most other platforms to make that switch for some time, if ever.

Isn't this article an indication that Debian intends to? I'd also guess there's a pretty good chance that distros based on Debian (e.g. Ubuntu) will follow that switch

As far as I know Debian intends to have no plain `python` on the default PATH once the python2 packages are removed, so that it will be up to the system administrator to decide where that will point.

See eg https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer.

(That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)

Interesting! That seems like a reasonable solution to me, but I also have no dog in that race since I don't use Debian or write much Python code.

Starting next year, I'd expect most other platforms will not include python2 in the default distribution, so the default "python" can either point to python3 or nothing at all.

Upgrading the OS is also annoying, so why not just stay in one place for next 5, 10, 50? years. If you don't upgrade your machine it probably will continue to work, python 2 won't disappear.

I wish PSF would pull the plug from python 2 much sooner so we wouldn't have to deal with whiners for 10 f...ing years. The problem with python 3 wasn't the incompatibility, the problem was keeping python 2 alive for so long. Other languages usually gave only 1 year and everyone moved, because they didn't want to stay behind.

Which other languages?

My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.

I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp).

People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes).

Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix.

And python2 still works, it just won't get new features.

[0]: https://youtu.be/LJh5QCV4wDg

> And python2 still works, it just won't get new features.

Probably more importantly, it wont get security fixes.

Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.

Those languages also don’t have massive runtime libraries with thousands of potential bugs that may even be security holes. They are not comparable in the slightest.

I have been extremely critical of the P2 to P3 drama, but to be totally fair, things haven't been as smooth as we like to remember in C++ land. While the c++11 standard (and successors) are highly compatible with c++98, most compilers at the turn of the millennium had questionable conformance and each compiler upgrade to a more recent and strict version was a lot of pain (I still remember the pain when GCC started enforcing two phase lookup).

I agree things could be better in c++, but never was never anything like python 3, redefining / , or removing printf. Also, usually once you fixed your code, it still worked in older compilers (although not always).

Yes also often the compiler would tell you exactly what to do (90% of the time it was a missing typename).

While I generally agree with your comment, Python generally gives easily accessible migration paths. Regarding your division example, you could import from __future__ integer_division (maybe it was another name?) Since I think Python 2.5 before it became the default in, I think, 2.7.

I wish the wallrus operator was available as a future import, bit it's not.

Also, Python never had printf. It had a print statement; print became a function in Python 3. Yes, its a syntax change, but its for the better. Having print as a first class statement expands its utility and versatility.

Removing printf was an example of a change C++ could make of similar effect (they could argue you should be using cout, so you don't need it). Sorry it was unclear

I don't understand people complaining about the removal of the print statement. Switching that to a function call is the easiest part of porting to Python 3. You don't even have to do it yourself, just run 2to3. If you're complaining about that I feel like you're just looking for something to complain about.

You are right. The print statement is easy to complain about. My main issue was all the strings/unicode changes, which were hard to track down as often code would continue to work until a non-unicode input came in, when it would error. Debugging all those issues took ages.

This is a good point, because of the dynamic nature of python, the incompatibility is not always visible at compile time (parse type?), but can happen at run time and only rarely.

You need very good test coverage.

Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9.

Tcl 8.3 to 8.4 when they added unicode support as well.

I believe PHP did similar thing.

> Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9.

It was a major version release; Ruby, through 1.8, used an version numbering scheme similar to the old Linux version numbering scheme; odd second digits were development major versions, even second digits were stable major versions.

1.9 was a slight break because it was a major release but, IIRC, seen as stable.

Ugh, another one of these threads.

Python 3 came out in December 2008. But for a lot of packages, it wasn't realistic to migrate until it was possible to support both Pythons from the same codebase. And that wasn't realistic until 2.7/3.3, which was 2012.

At that point the rising tide started and packages with no dependencies began doing dual support. But it was many years before there was enough coverage that application level packages like django could consider migrating.

So yes, the cutoff could have been somewhat sooner, but if the PSF had attempted to force a transition in 2009, it would have been a death knell for Python. Not even numpy was available for Python 3 until 2011!

Yeah, I started using Python 3 immediately. By biggest pain point was probably print going from a statement to a function, which while I agree it was the right move, I still have muscle memory that wants to use the statement. There are a few other pain points, like Unicode encoding, csv line endings. But, what prevented me from moving earlier was lack of 3rd party support. Things like DB and MQ access...

Python 3.3 was 8 years ago, packages started really migrating in 2015 when PSF stopped adding new features to Python 2.7.

The PSF actively discouraged folks from writing packages that were compatible with both. They wanted a hard schism and even tacit support for 2 was to reject the wishes of the church.

The original proposal from GvR for dual support in libraries was to release separate source, where the Py3 version would be the generated output of running source transformation tools like 2to3 against the Py2 source:

https://www.python.org/dev/peps/pep-3000/#compatibility-and-...

Not hard to see why this didn't get a lot of traction.

No they don’t. Step functions usually signify the change in evolutionary epochs. Meaning any time the change is too great, it literally means starting over.

Python barely survived 2to3, it should serve as a warning to every other system that thinks it can do a stop the world upgrade.

Honestly, this seems like the easiest possible thing to fix of all the things that might be broken about older code.

For that we have symlinks.

Surely the administrators of such systems can solve that problem with a few symlinks at most, not even code changes.

Sure, but those symlinks have to be consistently created and maintained, possibly on multiple new and existing systems.

If you already have infrastructure that does similar things, it's probably not much of an issue, but I can see missing or misdirected symlinks being a common problem. Maintaining the symlink in the distribution (Debian or whatever) reduces the chance of errors.

If there is any authentic popular demand for such a thing at all, I have no doubt that somebody in the python 2 community will see fit to publish a script that creates the appropriate symlinks.

I have no doubt that multiple people will publish such scripts, and that they'll be subtly incompatible.

(Cynical? Moi?)

Package maintainers have to deal with worse things than that. Also, major distributions migrated their core packages to Python 3 a long time ago. Even if Python 2 was supported for longer, the Python 2 age is definitely over for system programming.

Isn't Debian literally the one distro where that shouldn't be a problem?

You create a package called "constrictor2.7", and set it up to provide /usr/bin/python using update-alternatives. Then #!/usr/bin/python and #!/usr/bin/env python both work.

In the case, the name is utility and not an artifact. I would argue that having the same name is necessary to even having a workalike, at least for a system command and a symlink.

As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.

You can fork it, rename it, and make it provide python2 binary via both Debian alternatives and package-provides, then ask for inclusion in upstream. There's nothing that stops you and it's done for other languages as well. For example in C you have GCC and llvm providing cc.

Red Hat has already announced their intent to maintain Python 2 in RHEL for ~4 years.

Debian could just take RHEL's fork of Python 2. Why don't they do that?

Because:

* Everybody knows they should have moved to Python 3 for over three major versions of Debian stable.

* Debian is not committed to keep legacy software running in perpituity in new versions.

* For Debian Buster they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment!

* The next version of Debian stable will probably be released mid 2021 - long after Python 2's EOL of Jan 1.

* RHEL's Python 2 support amounts to life support at best.

* Keeping around legacy software takes precious volunteer time - which is all Debian has.

> they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment!

This is the entire point of a stable distro. To pick some software, stabilize it a specific api, and keep it supported. Upstream need-not support that specific version of a release, for reference, see the kernel.

Make your own Debian fork and stop pestering the rest of us about how volunteers should support software they aren't interested in.

Huh? I'm just saying it's not unreasonable to support software downstream that upstream doesn't. That's the entire point.

I don't care what Debian does at this point, too old for practical use.

> should support software they aren't interested in.

You mean like pestering all the other package maintainers to support python3 when they're not interested in doing that? That goes both ways. Nobody wanted python3, expect PSF. This is the continued backlash.

Because no-one on the Debian project wants to. If you'd like Debian to, feel free to volunteer, or pay someone to do it.

"Why should they do that?" is the better question. The tenets of Debian include stability. Having packages that may break at any time with no recourse is not stable.

RHEL's fork of Python 2 has a roadmap with clear dates of support. It won't "break at any time".

Fortran 77 doesn't have a stale compiler; modern Fortran compilers support Fortran back to the beginning of time. Almost all of the weirdnesses are limited to the front-end, so it's not that difficult to support.

Nothing about this is aggressive. And having maintained compilers for ancient languages is really really different from having an unmaintained, obsolete runtime/interpreter/ecosystem.

And nothing is stopping you from installing Python 2. All scientists I know rely on anaconda to manage their Python environment, and couldn't care less what the system python does. I really _don't_ want to rely on system python for reproducing my old results.

On the flipside: how useful is your code really if it's not reproducible with a modern Python version? From 3.3 to 3.8, there should be perfect backwards compatibility?

For packages, I can understand it, sure. So include a requirements.txt, and just spin up a 3.8 virtualenv to reproduce, no?

Backwards compatibility is there, but minor changes and patches might mean different things for certain users. One can never be sure without sifting throug changelogs and maintaining test suites. And that is for stuff you know you are looking for.

You mean like the recent issue that affected over a hundred papers because they assumed Python's glob module returned files in a sorted fashion and they depended upon the order the files were processed?

Well, that's kinda what I was saying. How useful is your code really, if it depends on the order in a list of files in a fragile way that's hard to fix if the order changes?

Probably very useful. Any big codebase is going to have lots of implicit dependencies by accident. It requires active development to stay compatible, and it's okay to not be perfect.

"In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that."

But if this is important to you then depending on the OS to provide your python seems like a bad idea, independent of the python2/python3 issues. Wouldn't it be much better to use something like conda / the anaconda distribution, so that you can specify precise versions of each library for your environment?

Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that?

> Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that?

What's to handle? Old versions of python2 packages are still in the online repos. The EOL means that there won't be any new releases to python. All of the old releases will still work though.

Distributing a container, virtual machine or something similar.

Yeah, our bioinformatics department is already using anaconda extensively.

The implementations of Algol and Fortran for Debian are maintained.

Recently I had to get some old Rails 1.8 apps running so I could get some screenshots for an upcoming project. Docker containers are great for this. It took a while to get everything working, but now I can export those container images and always have a version of these old projects I can run on a container runtime. I'll never use them for production of course, but they're good historically.

As others have stated, those are old implementations, but I'm sure Debain will still accept security patches for them. Python2 is about to lose major support. You cannot just let rotting dependencies stick around in your tree. You're not going to have a good time.

If people really want that stuff, they can pack it into a Docker container, or Snap/Flatpack/whatever garbage for old GUI applications.

Hats off to you for booting an old 1.8 app! That is prehistoric!

I guess in 10 years time, when dockerhub goes away, and most of the packaging scripts have broken online dependencies, a bunch of those docker images are going to be really hard to rebuild...

Fortran has maintained nearly full backwards compatibility.

Developers and scientists, in my experience, prefer to get the latest Python wheels from the Internet rather than reply on distributions to curate their packages. The consumers of distribution-provided packages is... other distribution-provided packages.

python is 29 years old :}

Reply on news.ycombinator.com