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

[Wes Turner]

On Mar 13, 2015 4:02 AM, "Bohuslav Kabrda" <bkabrda at redhat.com> wrote:
>
> ----- 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".

Values / Criteria (for dealing with change):

* backward compatibility (non-breaking)
* cross-platform support
* consistent file checksums
* interpreter arguments
   * PYTHONHASHSEED
   * -O2
* simplest solution
* convenience

Things that require/generate shebang lines:

* OS Packages in ./bin (can be expected to sed /usr/bin/env \(python.*\))
* ./scripts (should not need to be sed-ed to work w/ the current virtualenv
(?))
* console_scripts in ./bin (stubs generated with an explicit path; that can
later be 'made relocatable')

PEP 394: The "python" Command on Unix-Like Systems

* https://www.python.org/dev/peps/pep-0394/#recommendation
* http://legacy.python.org/dev/peps/pep-0394/#recommendation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150313/209b6b46/attachment.html>