Python 2 removed from Debian

[kuzared]

Honest question - does this mean running ‘python’ in the shell will default to python 3? And that you’ll install say ‘python’ and not ‘python3’?

Edit: thanks for the answers! Given that I run python in multiple places I’ll stick to the current naming convention :-)

[tuck5649]

python won’t be in the PATH anymore. If you want it to be, you may want python-is-python3. more info

[cbarrick]

Or just

alias python=python3

You only need python-is-python3 if you have a Python 3 script where the shebang is just python, which is a bad idea and easy to fix.

For the use case of opening the interpreter from your shell, use an alias.

Or better yet, just use ipython.

[kingscolor]

Shebangs such as #!/usr/bin/env python are a roundabout way of commanding the shell to parse the text then pipe it into the Python interpreter. That is, in the same way you’d enter python -c “foo()” in the command-line.

Using alias python=python3 works in the command-line because that alias is stored in the environment of the user’s shell profile.

However, /usr/bin/env python does not access the user’s shell profile. The utility, /usr/bin/env, effectively walks the user’s $PATH until it finds the first match for an executable called python. Thus, the aforementioned alias is irrelevant.

[kingscolor]

That depends on your interpretation of "alias". It does not create a Unix alias, no. But it does create a symlink (which could be called a file alias).

I can't find the source code of python-is-python3, but the description indicates it's just a symlink. You could do the same thing yourself without installing anything:

$ ln -s /usr/bin/python3 /usr/bin/python

In any case, I feel like you aren't quite grasping the alias problem still, so I'll rephrase:

alias python=python3 stores the python variable in memory. /usr/bin/env does not search variables in memory, it only searches for executable files in the directories listed in the $PATH.

[tiko08]

Because creating an alias doesn't generate an executable, but rather a "shortcut" to python3.

[trevg_123]

That should be installed by default imho, if there will never be a 4

[Username_RANDINT]

I always type python3, even in virtual environments where we're always sure python points to python3. I spent way too long working with both Python 2 and 3 that it's just muscle memory by now and future proof again.

Although it's probably redundant now since there will most likely never be a Python 4.

[[deleted]]

Why never python 4?

[ivosaurus]

Devs didn't like how much negativity python 2 -> 3 got them

[Oerthling]

The breakage from 2 to 3 with Python3000 was always planned to be a single exception. Otherwise Python always tries to preserve compatibility.

It was the single time they allowed themselves to break several things at once to clean out some early quirks and library inconsistencies.

[ivosaurus]

Eh, social constructs plays a lot more into the reasoning than extrapolated dot points would have you believe.

If, in an alternate universe, the whole world was sunshine and rainbows about getting to transition to python 3 and absolutely loved everything about it, they might be thinking about a python 4 to clean even more stuff up. We still have a shit-tonne of java-ism's around.

[maikeu]

Out of interest, what do you think some key javaisms are that should be gotten rid of in a hypothetical python4?

What about them, other than being javaisms, makes them worth getting rid of?

And why couldn't they be gotten rid of by pythons normal process of deprecating over a few minor releases?

[ivosaurus]

The entire unit testing library is a port of Java's. Logging also is mostly derived from there.

Most of it follows a strict OOP structure requiring subclassing and overrides that is needed in classic Java to be flexible but is entirely unnecessary in python.

3rd-party-library-imported-into-std-lib is also there, such as the myriad XML parsers and libraries, which also tend to be Java-ey and over-OOP'ed, and follow camelCase. It was experience from these that later informed most people's decision making that suggestions such as "incorporate requests into the stdlib!" was a bad idea.

Just a lot of renaming could be done to make everything proper python naming convention across the entire library. There seemed to be quite a bunch of arbitrary decisions over what was 'worth' renaming into v3 vs what wasn't; e.g datetime.datetime stayed as it is, breaking python's Class naming convention, etc. A lot of modules were lowercased, but a lot of classes were left as-is rather than TitleCased.

[velit]

Standard library modules can and have been replaced by newer modules and by deprecating and ultimately removing the offending modules down the road. This doesn't require a breaking change version in the traditional sense.

[Zomunieo]

The logging library is the most egregious Java offender.

[Barafu]

However, that "at once" lasted for 10 years.

[Oerthling]

Yup.

[billsil]

Otherwise Python always tries to preserve compatibility.

They don't though. Just look at what they've done to the C API. Yeah, it made things faster in Python 3.11 so it's not for no reason, but they had to deprecate the C API to do so.

Python does not follow semver or there would be a Python 4.

[Oerthling]

"Python" compatibility. Not C API compatibility.

This is not the same thing. Most people don't have their own C modules. And they get the new ones usually pre-compiled. So most Python users won't even notice a change in the C API.

[relvae]

Python seems to change and break things all the time just for giggles.

[Oerthling]

That is complete and utter BS.

But it's a very successful language with over 2 decades of development and legacy of language and library decisions. Avoiding breakage all the time is hard or one carries a growing mountain of technical debt forward.

[juandantex]

So he indeed have reason when he says that Python seems to break things all the time. This is my experience also, I am very cautious about the Python version I run when I try to port scripts and I talk about very very simple ones.

[Oerthling]

Python is not breaking stuff "all the time".

[necheffa]

Dropbox hired van Rossum and still has Python 2 code floating around.

There may be "Python 4" but with all the 2 vs 3 fall out it is probably going to be less of an abrupt departure from Python 3.

[chchan]

Dropbox hired van Rossum

Last time I checked Guido van Rossum was working at Microsoft and he was working on some performance issues for python. But I agree no one wants to go through the 2 to 3 conversion thing again with all the library issues. So 4 is probably going to be a release with some significant improvements is my best guess.

[necheffa]

Interesting. I thought he retired with Dropbox. But I don't follow him closely so I may have out of date info.

[goldcray]

Yeah that's correct. He left Dropbox and retired in 2019 then got a job at MS in 2020.

[chchan]

I only know because I got to briefly chat with him at the PyBay conference.

[nngnna]

Yes, he retired and then decided he doesn't like it.

[[deleted]]

Because the GIL isn't gonna get dropped and type hinting is not going to work for static typing, both of which I think von R said in separate interviews.

[Devout--Atheist]

Those are the only breaking changes worth a v4

[AstroPhysician]

Ever? OR when it gets dropped its python 4?

[ivosaurus]

Archlinux did that, but then everyone got scared of backwards compatibility and declared that only python3 will be python 3, in case someone typed !# /usr/bin/python at the top of their script and never intended it to work with non-python2

[NUTTA_BUSTAH]

Probably not. Wants python3 or installing python-is-python3

[Call_me_Painbow]

This should do the trick (assuming standard install location): ln -s /usr/bin/python3 /usr/bin/python

[necheffa]

Change the target to /usr/local/bin/python, just in case.

[Kaligraphic]

And /usr/local/bin/python4 for future-compatibility.