When should Python 3.3 become the default?

[Barry Warsaw]

On Oct 19, 2012, at 01:18 PM, Steve Langasek wrote:

>There are a range of different porting strategies that people might use,
>depending on precisely which python versions they need to support.  However,
>for anyone doing *new* work porting to python3, if we decide to go with 3.3
>for raring, I don't see any reason that they should worry about 3.2 for
>12.04.  If the software wasn't already using python3 in previous releases,
>it doesn't make sense to (and probably isn't possible to) switch it to
>python3 after the fact.  So if you're trying to support precise-raring in a
>single codebase that's currently python2-only, it would be better to focus
>on 2.7+3.3 and ignore 3.2 entirely.
>
>(You're of course correct where 10.04 and 2.6 are concerned - and I have no
>strong opinion about whether unicode_literals in particular are worth
>skipping 3.2 for.)

Probably not.  The re-introduction of u-prefix in Python 3.3 (PEP 414) was
accepted for a fairly limited set of use cases, web apps and WSGI in
particular.  The experts in those domains were persuasive in arguing that the
lack of such a prefix was a major impediment to their porting to Python 3, and
given the luminaries involved, I'm inclined to trust their opinion.

In almost all other cases though, u-prefix should be unnecessary at best, and
a crutch at worst.  I really don't want to see a lot of Python 3 code use
u-prefixed literals when they don't need to.  Even when supporting back to
Python 2.6 in a single code base, bytes literals (b-prefixes) and
future-imported unicode_literals should be the right way to go.  If Python 2
support is not a requirement, then there really is almost no reason not to
just use byte literals and unadorned strings (without the noop-in-Python3
future-import).

I think in general, it should not be too difficult to support Python 3.3 if
you already support 3.2.  There are a small subset of known failures in
Debian:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=python3.3

some of which are already fixed or with proposed fixes.  I suspect the others
will be relatively shallow.  I agree that we're probably not looking at many
(if any) packages that have to still support 3.2 in 12.04, and it's probably
not that big of a deal even for backporting to 12.10.

All new code should be written for 3.3.  The one big rewrite I've been working
on recently, friends-service (nee gwibber-service) has a few conditional
3.3-isms in it that haven't been thoroughly tested because of the lack of
extension modules for 3.3, but I think that code will work, and we'll be able
to clean up a few things once a full 3.3 stack is available in raring.

I have no doubts that at some point in raring, we will want to switch to 3.3
as the default, if not the only version.  This will give us time to adjust,
and stability in Python 3 versions all the way to 14.04 LTS.  The question is
whether to JFDI or wait a bit and see what fails.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121019/25a1f10e/attachment.pgp>