When should Python 3.3 become the default?

Barry Warsaw barry at ubuntu.com
Mon Oct 22 14:03:11 UTC 2012

On Oct 20, 2012, at 01:45 PM, Matthias Klose wrote:

>> If the python3.2->python3.3 porting work is small enough to do in one
>> cycle, I think it's beneficial for us to focus on this porting exclusively
>> and *not* worry about making packages work with both python3.2 and
>> python3.3,
>If you need fixing a package for a new python version, how often do you break
>a previous version? Will upstreams even accept this kind of patches?

I suspect that any upstream that already supports Python 3.2 would gladly
accept patches to also support 3.3 (if any are even necessary).  I'm sure
*dropping* 3.2 compatibility probably won't be acceptable for packages that
already support it, but it might also be difficult to convince the ones that
haven't moved to Python 3 yet to skip 3.2.  Other distros (including Wheezy
btw) will still have 3.2 as their likely default Python 3 for a while.

>If you think that the reintroduction of u"" strings will help porting, I'll
>backport this to 3.2 temporarily (provided that it doesn't end up in a

I don't think this will be necessary, but I also wouldn't recommend doing it.
We definitely don't want to ship an official Python 3.2 with u-'' prefixes
enabled, and I suspect the number of packages it will actually help is going
to be pretty small.

>Point 2) is (afaics) done.  I do not want to rely on the 3.3 work being done
>in a PPA only, this time is lost during the development cycle. It doesn't
>expose 3.3 until it's the default, and things like the dbus-python/3.3 issue
>mentioned earlier in the thread show that it's not always easy to get these
>PPA configurations correct (and yes, we had some issues back with the 2.6/2.7
>tests in a PPA too at the end of the last year, which then came up as a
>surprise in the archive).
>So lets open with 3.3 as a supported version from the start, and drop 3.2 when
>3.3 is made the default (or shortly after).  Adding a new version doesn't
>break the existing packages in the archive, issues are usually only exposed at
>build time. I think it's a must to check for the common site/dist-packages
>layout. If people do not want to address the pyqt "tooling" issues, these
>should be at least documented in the bug tracker.
>6) is not really an option (but maybe it's expected from your position to
>provide such a fallback ;)

I just want to reiterate that my biggest concern is the potential for Python
3.3 support work to detract from the general Python 3 porting effort.  As long
as the former doesn't consume all our time, and we can still make progress on
the latter (if not accomplish it for task:ubuntu-desktop), then I'm all for
going ahead.  If not, then I think we need a fallback position.

ISTM that we really don't have a good idea of the effect of Python 3.3 will
be, and we need to do rebuilds in order to find out.  Whether this happens in
a PPA, a local build or the primary archive, we still need to do it and gather
the information.  If we do it in the archive (i.e. start with 3.3 supported
but not default) and we need a fallback, then I think that would be to peg the
maximum Python 3 version for such packages at 3.2 so build failures against
3.3 won't break the package.  But we can do this much later in the cycle if
necessary (and of course, I hope it won't be).


More information about the ubuntu-devel mailing list