I'm at that awkward phase where python2 can't be dispensed with, and python3 is mainstream. So whatever I set the /usr/bin/python symlink to is unsatisfactory.

Is there some wheeze where python2 or python3 can figure this out for themselves, and the correct interpreter invoked - a bash or python script, perhaps?

I wonder...if you could write a little script that would invoke python3 by default to run a program, collect the return code and check it, then in the event of a failure do it again with python2.

I have both on my CentOS 7 system. I always use a shebang and make them self executable so python 3 scripts have #!/usr/bin/python3.

No. Because there is nothing in the python script itself that tells the interpreter or other application this is python2 or python3. So you either invoke correct python version manually, or as above have a bash script for each one set to execute the correct interpreter for given python program. Of course the correct way is to just move to python 3 and be done with it . This issue came up a lot with RPI work back when RPI was new(ish). Now everything uses Python 3. At work I was lucky in a sense, as we started using python 3 (3.3) from the beginning of bringing Python into the company.

Thanks for the replies.

I've moved the symklink over to python3. It seems the way to go is to try python2 on any scripts that puke. Putting a number in the shebang is good practise - presumably there will be python4.

The fortunate thing is that python scripts seem to puke quickly. So there's not much time wasted. I'll go back to the symlink again and change it once more from 'python3.9' to 'python3.'

EDIT: @Hazel: I had thought of grepping for the shell. But if people writing python3.x scripts use '#!/usr/bin/python' that all comes unstuck.

if it is important you need to use python2 and python3 (or python3.11) instead of python. In general python itself is just a symlink to the system default python version, which should not be modified. Otherwise you can install different python versions onto your host.

Yes, but I think the point business_kid was making is that it's tiresome to have to do that. In the good old days, life was simpler: you just typed "python" and it always worked. Now it works most of the time, because most python is python3, but there are always scripts that haven't been converted and crash on you. It would be nice to have a pre-run check which could detect which version of python was being used and invoke the correct interpreter seamlessly.

It can't be done reliably by reading the shebang because that might just say "python". But maybe if the script could be run through in the background with python3, a crash would trigger a run in earnest with python2. Or there might be problematic function names to look out for. Something like that.

I think the development of multiple software (multiple versions) should be banned because it is too tiresome.
Otherwise you are right.

But I think the software issues become clearer when you consider two incompatible command interpreters with programs gradually migrating - bash, for instance.

I don't know Python well enough to know, but are there different command structures or keywords that can be checked for? I did actually have a python module (a few lectures) back 10 years but we were doing 1½ years of material in one year, because the course got truncated mid way. So I had a severe case of Knowledge Bulimia (Learn in for the test & forget it after ).

How would you go about that? Remember, it's not primary programs we are talking about here; it's ancillaries. In this case it's a script interpreter but you get something similar happening with certain popular libraries such as gtk.

In both cases the situation is asymmetrical. Script writers know what interpreter they should use but those who program the interpreters don't know about all the scripts that have been written in their language. Similarly programmers know what major version of a library they need to use but library developers don't know what programs might want to link to them.

So if either a scripting language or a library gets a major upgrade, there will be loads of operational software out there that will no longer work and no way of tracing it all and providing warnings or upgrades. You'd have major chunks of software failing all over the place because some carpet was pulled out from under their feet.

So what happens in practice is that the new is issued in parallel to the old with a slightly different name. So we have python2 and python3, gtk-2, gtk-3 and now gtk-4. I agree that its a mess but just letting things crash because something changed upstream doesn't seem to me like an improvement.

This is the nature of the development. You can try to be backward compatible, but it will cost more and more and will force the developers to be conform with outdated and old design rules (and compatible with some abandoned parts).
And sometimes they must just break it to to be able to introduce new kind of limitations.
Inevitable.

The way Linus handles changeovers is good, imho.

In 2004, the kernel officially said farewell to most of: ISA cards; /dev/ttyS*; /dev/lpt*; only 16 interrupts; The overbearing restriction of certain devices wanting/needing certain interrupts; Fixed hardware I/O addressing, etc.

But they weren't just dropped like a stone. Backward compatibility facilitated their use for some time, until they were fully deprecated. I was still using an ISA card until at least 2006. Maybe that had more to do with Mandrake's & SuSE's choice of kernels - I dunno.

I deleted python2 years ago. Everything just works. Don't forget to
Reference: https://docs.python.org/3/howto/pyporting.html