On 03/08/2012 08:40 AM, Ian Clelland wrote:
> On Thursday, March 8, 2012, Aymeric AugustinLet's please not rehash this discussion here, it was already beaten to
> <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)
death on the python-dev mailing list.
>> I hope we'll take advantage of this new feature in Django; however,Note that the current version of Vinay's port (since it was updated to
> 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
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 supportI think the fact that the next Ubuntu LTS will include Python 3.2, and
> 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
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.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.