Hi Ian, On 03/08/2012 08:40 AM, Ian Clelland wrote: > On Thursday, March 8, 2012, Aymeric Augustin > <aymeric.augus...@polytechnique.org > <mailto:aymeric.augus...@polytechnique.org>> wrote: >> PEP 414 was accepted a few days ago. It's designed to make it easier > to support 2.6, 2.7, 3.3+ on the same codebase. > > (finishes reading) > Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to > encourage developers to adopt Python 3, it is declared that Python 3.9 > will be exactly identical, in syntax and semantics, to Python 2.6.7"
Let's please not rehash this discussion here, it was already beaten to
death on the python-dev mailing list.
>> I hope we'll take advantage of this new feature in Django; however,
> that means a large update (if not a reboot) of the py3k branch.
>
> Sarcasm aside, the only thing that this PEP does is force us to consider
> the minimum "starting version" of Python 3 that we want to support. If
> we declare that Django 1.5 will run on Python 3.2+, then we can ignore
> this PEP, and continue to use the u() and b() functions in the py3k
> branch, until 3.2 support is one day deprecated.
Note that the current version of Vinay's port (since it was updated to
account for dropping Python 2.5 support post-1.4) does not use u() and
b() functions, it uses "from __future__ import unicode_literals". This
means that the only place string wrappers are needed is in the few
places where a "native string" is needed ("str" on both Python 2 and 3).
Vinay posted numbers to python-dev indicating that there is no
measurable performance overhead in the current port.
> On the other hand, if we can say that Django 1.5 will only support
> Python 3.3+, then there will never be a version of Django that needs to
> run on 3.2, and we can remove those functions from the py3k branch. Not
> really a reboot, just one transformation that can now be removed.
> (probably giving us a few % speed improvement)
>
> I don't think we should base the decision on this PEP, though. More
> important factors are probably the release schedule for 3.3 (August?)
> and how that meshes with the 1.5 development cycle, as well as vendor
> support for, and availability of, Python 3.3. Right now, there are a lot
> of people with access to long-term vendor-supported Python 3
> environments, but nobody has 3.3. If we say that you can't upgrade to
> Python 3 until you can get a full 3.3 environment, how will that affect
> the usefulness of support in Django 1.5?
I think the fact that the next Ubuntu LTS will include Python 3.2, and
it won't be possible to make use of PEP 314 on Python 3.2 without
install-time-transformation hacks, is a strong argument in favor of
sticking with a working unicode_literals port rather than reworking it
to use PEP 314.
Carl
signature.asc
Description: OpenPGP digital signature
