[Python-Dev] PEP 414

[Chris McDonough]

On Fri, 2012-03-02 at 15:39 -0500, Barry Warsaw wrote:
> On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote:
> 
> >FWIW, I think this issue's webness may be overestimated.  There happens to be
> >lots and lots of existing UI code which contains complex interactions between
> >unicode literals and nonliterals in web apps, but there's also likely lots of
> >nonweb code that has the same issue.  If e.g. wxPython had already been
> >ported, I think you'd be hearing the same sorts of things from folks that had
> >investments in existing Python-2-compatible code when trying to port stuff to
> >Py3 (at least if they wanted to run on both Python 2 and Python 3 within the
> >same codebase).
> 
> Okay, I just want to be very careful about the message we're sending here,
> because I think many libraries and applications will work fine with the
> facilities available in today's stable releases, i.e. unicode_literals and
> b-prefixes.  For these, there's no need to define "native strings", nor do
> they require language constructs above what's already available.

Although the change makes it possible, and it is very useful for very
low level WSGI apps, the issue this change addresses really isn't really
100% about "needing to define native strings".  It's also just
preservation of a resource in pretty short supply: developer energy.
You will probably need to modify less code when taking piece of software
that currently runs on Python 2 and changing it so that it runs on both
Python 2 and Python 3, without needing to worry over the unintended
consequences of using a unicode_literals future import or replacing
existing u'' with a function call.

This, IMO, can only be a good thing, because the nominal impact of some
future user who must now understand u'' syntax is (again IMO) not as
consequential as that user having less software to choose from because
porting to Python 3 was just that much harder for existing Python 2
developers.

- C