Switching to Python 3

[Toshio Kuratomi]

On Fri, Aug 03, 2012 at 04:42:02AM -0400, Bohuslav Kabrda wrote:
> ----- Original Message -----
> > On Fri, Aug 3, 2012 at 8:57 AM, Bohuslav Kabrda <bkabrda at redhat.com>
> > wrote:
> > > Hi,
> > > I'd like to start a discussion about the release where we should
> > > switch to Python 3. As I have learned recently, Ubuntu 12.10 will
> > > have Python 3 as default [1], which makes me a sad panda :(
> > > We always take pride in being close to upstream and having the
> > > bleeding edge. Python 3 is stable and more and more libraries
> > > support it. So I'd like to propose an idea to switch to Python 3
> > > for Fedora 19.
> > 
> > In which a way do you want to switch to python3?
> > For me, that means any mention of "python" is synonym to "python3",
> > which leads to the question, what is inside a python-foo package?
> > The module foo, built for python3?
> > 
> 
> As you say, switching means /usr/bin/python -> /usr/bin/python3. And yes, that is a very valid point about the naming, I think.
> 
Porting, taking those ports upstream, and even *tiny shudder* carrying those
python3 patches locally for a loooong time, I could support.

Switching /usr/bin/python to point to /usr/bin/python3 I'd be very much
against (at least for several years):
  http://www.python.org/dev/peps/pep-0394/

has a section that says it may someday be updated to recommend changing
a /usr/bin/python symlink to point at python3.  I would wait to make the
link change until that PEP is updated (or many other unix distributions are
also ready to make the switch).  Switching the link is a largely symbolic
gesture that creates more work for package maintainers, more work for end
users, and more work for developers (who all have to find uses of
/usr/bin/python and change them to /usr/bin/python2).

Switching /usr/bin/python to /usr/bin/python3 sacrifices practicality to
purity which is unpythonic :-)

> > It would be best to rename all python-foo packages, to python2-foo or
> > python3-foo and don't allow subpackaging of modules, which provide
> > multiple python versions. And when that's consistent, we can switch
> > /usr/bin/python to python3.
> > 
> 
> I agree about the renaming. Having said that, I don't like that the users will need to install python2-foo or python3-foo, not just python-foo. On the other hand, the normal users will just get stuff and update it. The developers using various versions of python might actually appreciate the knowledge of what they are installing.
> 
One of the things that tomspur and I talkd about relating to this... There's
a large potntial for confusion (in, for instance, bugzilla) if we simply
rename python-foo to python2-foo if the python-foo package was building
a python3-foo subpackage.  If you find a bug in python3-foo, you'd need to
file it against python2-foo in bugzilla... very non-intuitive.

A way to deal with this would be to stop shipping python3-foo as
subpackages.  Modules for python3-foo would have to be from separate srpms.

Another way would be to have empty python-foo main packages that generates
python2-foo and python3-foo subpackages.  That's kinda ugly though.

Regarding users needing to install python2-foo vs python3-foo: I'd propose
virtual provides *for backwards compatibility*.  For several years, yum
install python-foo would match a 
  Provides: python-foo = %{version}-%{release} 

in the python2-foo package.  At some point we'd decide these were no longer
worthwhile and get rid of them.  Note that this would only be for backwards
compat.  We'd never change them to install python3-foo.  It's just to wean
users off of python-foo meaning python2-foo.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20120803/1a846d45/attachment.sig>