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@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