[Python-ideas] Migration of /usr/bin/python to python3

[Bohuslav Kabrda]

----- Original Message -----
> On Mar 11, 2015, at 09:38 PM, M.-A. Lemburg wrote:
> 
> >I think the migration should start with modifying scripts to use
> >
> >#!/usr/bin/env python2
> >
> >when they are Python 2 only (*) and
> >
> >#!/usr/bin/env python3
> >
> >when they are Python 3 only and
> >
> >#!/usr/bin/env python
> >
> >only when they support both Python 2 and 3.
> 
> Mostly, I agree, although I would not recommend /usr/bin/env for system
> installed scripts.  Using /usr/bin/env is fine for development trees, but a
> really bad idea for anything installed in system locations.  Modify your
> suggestion to /usr/bin/python2 and /usr/bin/python3 and I'm on board. :)

+1, the system scripts should use system Python explicitly to keep working when user's environment changes. I'm not sure about Debian/Ubuntu, but we do this in Fedora as much as we can.
And while I'm primarily a packager, I also use /usr/bin/env python[2|3] while coding, because it's just more handy during development.

> I would very much like to see explicit use of /usr/bin/python2 replace
> /usr/bin/python for scripts.

+1 (or, better yet, /usr/bin/python3 ;))

> Then I think the problem is, what do users expect when they type
> 
> $ python foo.py
> 
> at their shell prompt?

For more than a year now, I've been trying to push python 3 as default in Fedora. "Default" means that it should be the only Python on live media/cloud images/... and various system applications and system scripts will run on it. I want Fedora to follow PEP 394, so this doesn't mean switching /usr/bin/python to Python 3, but that's one of the biggest sources of confusion. Most users expect /usr/bin/python to point to "the" Python.

We're not switching for switching /usr/bin/python (for now) for several reasons:
1) PEP 394
2) System packages still using /usr/bin/python
3) Custom user/sysadmin scripts pointing to /usr/bin/python

Point 1 is a recommendation that can change in time, since it's in hands of Python upstream (but then again, it's mostly there because of 3, I think); we'll make point 2 go away in time, because that's something that we can change. Point 3 is the real issue, because (from my experience) there are tons of users/sysadmins that use Python as a shell with nice features and don't really care about what's going on in Python upstream. These scripts are outside of Python upstream and distro control and we can't do anything about them. My thinking is that these won't change - not now, not in two years, not in ten years. The only way to change them is to break them - and then the real question is: do we want to break them or do we want to keep them working forever? (well, at least until we retire Python 2, which would make /usr/bin/python disappear completely)

So what can be done:
a) PEP 394 changes in few years to recommend pointing /usr/bin/python to Python 3, thus breaking (3). Hopefully this would happen at point where most distros are ready (and willing) to do the change.
b) PEP 394 never changes while Python 2 is supported, suggesting switching /usr/bin/python after Python 2 EOL (2020?).
c) PEP 394 never changes, not even after Python 2 EOL.
d) We remove /usr/bin/python. I've already heard several people suggesting this, but I'm not sure what that should mean for us on distro level. For example, should the system-packaged pip have /usr/bin/pip then? Or should that be removed too? Either way, this would nicely solve (3), since people would just get "python not found" and would have to investigate and learn what's going on, doing an explicit decision about which Python they want to use. On the other hand, I can pretty much guarantee that lots of people would hate this, since they just want to type "python" :)
e) Something else?

I have to say I prefer a), since I think that we should just move forward at one point and make Python 3 "the Python". My second preference would be d), since that at least doesn't make it look that Python 2 is still "the Python".

> Cheers,
> -Barry

-- 
Regards,
Slavek Kabrda