Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Django participation in Google Summer of Code 2012
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Carl Meyer  
View profile  
 More options Mar 8 2012, 11:48 am
From: Carl Meyer <c...@oddbird.net>
Date: Thu, 08 Mar 2012 08:48:56 -0800
Local: Thurs, Mar 8 2012 11:48 am
Subject: Re: Django participation in Google Summer of Code 2012

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
< 1K Download

 
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.