On Nov 22, 2011, at 09:13 AM, Toshio Kuratomi wrote: >For Fedora (and currently, Red Hat is based on Fedora -- a little more about >that later, though), we have parallel python2 and python3 stacks.
Debian (and thus Ubuntu) also has separate Python 2 and 3 stacks. In general,
if you have a Python package (e.g. on PyPI) called 'foo', you'll have a Debian
binary package called python-foo for the Python 2 version, and python3-foo for
the Python 3 version.
/usr/bin/python will always (modulo perhaps PEP 394) point to Python 2.x with
Python 3 accessible via /usr/bin/python3. The minor version numbered Python
binaries are also available.
Debian's infrastructure makes it fairly easy to support multiple versions of
Python at the same time, and of course to support both a Python 2 and 3 stack
simultaneously. It's also fairly easy to switch the default Python version.
Binary packages containing pure-Python are space efficient, sharing one copy
of the Python source code for all supported versions. A symlink farm is used
to manage the incompatibilities in .pyc files, but only for Python 2, since
PEPs 3147 and 3149 solve this problem in a better way for Python 3 (no symlink
farms necessary). The one additional complication though is that extension
modules must be built for each supported version, and all .so's are included
in a single binary package. E.g. if python-foo has an extension module, it
will contain the 2.6 .so and the 2.7 .so. For the next version of Ubuntu, we
will be dropping Python 2.6 support, so our binary packages are rebuilt to
contain only the 2.7 version of the extension module.
Details on how Debian packages Python, including its deviations from upstream,
are available here:
http://wiki.debian.org/Python
Ubuntu's deviations from Debian and other details are available here:
https://wiki.ubuntu.com/Python
>Unlike Barry's work with Ubuntu, though, we're mostly chiselling around the
>edges; we're working at the level where there's a module that someone needs
>to run something (or run some optional features of something) that runs on
>python3.
This is great, because it means Fedora's taking kind of a bottom-up approach,
while Ubuntu is taking a more top-down approach. Working together, we'll
change the world. :)
The key here is that we push as many of the changes as possible as far
upstream as possible. I know Toshio and David agree, we want to get upstream
package authors and application developers to support Python 3 as much as
possible. I hope there will be no cases where a distro has to fork a package
or application to support Python 3, although we will do it if there's no other
way. Most likely for Ubuntu though, that would be pushing the changes into
Debian.
>Where distros aren't working on parallel stacks, there definitely needs to
>be some transition plan. With my experience with parallel stacks, the best
>help there is to 1) help upstreams port to py3k (If someone can get PIL's
>py3k support finished and into a released package, that would free up a few
>things). 2) open bugs or help with creating python3 packages of modules
>when the upstream support is there.
+1
>Depending on what software Barry's talking about porting to python3, that
>could be a big incentive as well. Just like with the push in Fedora to have
>pylons run on python3, I think that having certain applications that run on
>python3 and therefore need to have stacks of modules that support it is one
>of the prime ways that distros become motivated to provide python3 packages
>and support. This is basically the "killer app" idea in a new venue :-)
Again, wholehearted +1.
For now, we are not spending much time on server applications, though I've
seen promising talk about Twisted ports to Python 3. We're looking
specifically at desktop applications, such as Update Manager, Software Center,
Computer Janitor, etc. Those may be fairly Ubuntu and/or Debian specific, but
the actual applications themselves aren't too difficult to port.
E.g. switching to Gnome object introspection, which already supports Python
3. We can easily identify the dependency stack for the desktop applications
we're targeting, which leads us to looking at ports of the dependent
libraries, and that benefits all Python users.
Our goal is for the Ubuntu 14.04 LTS release (in April 2014) to have no Python
2 on the release images, or in our "main" archive, so everything you'd get on
your desktop in a default install would be Python 3. For the upcoming 12.04
LTS release, I'd be happy if we had just a couple of Python 3 applications on
the desktop by default.
I see the work going on in Fedora/RedHat, Debian/Ubuntu, and other
distributions as applying some positive momentum on pushing the Python
community over the tipping point for Python 3 support.
Cheers,
-Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
