A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-February/117055.html below:

[Python-Dev] PEP 414 - Unicode Literals for Python 3

[Python-Dev] PEP 414 - Unicode Literals for Python 3Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Feb 28 14:02:18 CET 2012
Nick Coghlan <ncoghlan <at> gmail.com> writes:

> 
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip <vinay_sajip <at> yahoo.co.uk>
wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time a
> > change is made, writing to a separate directory, or else a fixer which is
> > integrated into the editing environment so it knows what changed. This is
> > painful, and what motivated PEP 314 in the first place - which seems ironic.
> 
> No, the real idea behind PEP 414 is that most ports that rely on it
> simply won't support 3.2 - they will only target 3.3+.

Well, yes in that the PEP will only be implemented in 3+, but the motivation was
to make a single codebase easier to achieve. It does that if you take the narrow
view of 2.6+/3.3+, but not if you factor 3.2 into the mix. Maybe 3.2 adoption is
too low for us to worry about here, but I for one certainly wish it hadn't been
relegated to being a 2nd-class citizen.

> The u"" fixer will just be one more tool in the arsenal of those that
> *do* want to support 3.2 (either because they want to target Ubuntu's
> LTS 3.2 stack, or for their own reasons). All of the other
> alternatives (such as separate branches or the unicode_literals future
> import) will also remain available to them.

Right, I get that - as I said, unicode_literals is my preferred path of the
options available. It's a shame to see this sort of Balkanisation, though. For
example, if Django retains u'xxx' literals (even though I've ported it using
unicode_literals, they may choose a different path officially), users wanting to
work with it using 2.6/2.7/3.2/3.3 (as I do now) are SOL as far as a single
codebase is concerned. Of course, when you're working on your own project, you
can call the shots. But problems can arise if you have to work with an external
project, as many of us frequently do.

Regards,

Vinay Sajip

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4