Of course that Mailman is Python 2. The Python project’s extremely badly handled transition includes a recommendation to change the meaning of #!/usr/bin/python from Python 2, to Python 3.
But Python 3 is a new language, barely compatible with Python 2 even in the most recent iterations of both, and it is usual to need to coinstall them.
Happily Debian have provided the python-is-python2 package to make things work sensibly, albeit with unpleasant imprecations in the package summary description.
Several things are worth pointing out here:
Enough compatibility shims were provided that even large, complex Python projects were able to maintain a “single codebase” approach during porting, meaning that the same codebase simultaneously was able to run on Python 2 and Python 3, only dropping Python 2 support later when the project felt ready.
“Even in the most recent iterations of both” seems to imply that somehow this is a new thing. Python 3.0 was released fourteen years ago. Even if one charitably assumes holding off on serious porting work until Python 3.3, which was the first release to really be suitable for production and “single codebase” use, we’re still talking about a decade here.
The question of which interpreter python invokes was meant to be answered by PEP 394, which originally specified that python should invoke Python 2, and that invocation of Python 3 should require explicit opt-in via python3. I’ll let the PEP itself explain what happened:
However, these recommendations implicitly assumed that Python 2 would always be available. As Python 2 is nearing its end of life in 2020 (PEP 373, PEP 404), distributions are making Python 2 optional or removing it entirely. This means either removing the python command or switching it to invoke Python 3. Some distributors also decided that their users were better served by ignoring the PEP’s original recommendations, and provided system administrators with the freedom to configure their systems based on the needs of their particular environment.
So… yeah. They tried to do what the author thinks would have been the right thing. Of course, that approach also assumed that someone would actually go through a transitional period of having both Python 2 and 3 available on the same machine in order to provide sufficient time for users to test their scripts. Judging by the infrequency of operating-system upgrades on this server, I am guessing that such a transition period never occurred.
This is definitely “server as pet” rather than “server as cattle” territory!
Almost like a member of the family.
Is this the chiark of chiark.greenend.org.uk fame?
The same. The blog author is aka http://www.chiark.greenend.org.uk/~ijackson/ (and also, the original author of dpkg, which probably helps a bit in a situation like this).
Several things are worth pointing out here:
pythoninvokes was meant to be answered by PEP 394, which originally specified thatpythonshould invoke Python 2, and that invocation of Python 3 should require explicit opt-in viapython3. I’ll let the PEP itself explain what happened:So… yeah. They tried to do what the author thinks would have been the right thing. Of course, that approach also assumed that someone would actually go through a transitional period of having both Python 2 and 3 available on the same machine in order to provide sufficient time for users to test their scripts. Judging by the infrequency of operating-system upgrades on this server, I am guessing that such a transition period never occurred.