[Python-Dev] Proposal: from __future__ import unicode_string_literals

[Thomas Wouters]

On Sun, Mar 23, 2008 at 8:37 AM, Lennart Regebro <regebro at gmail.com> wrote:

> Eric Smith wrote:
> > It's not implementable because the work has to occur in ast.c (see
> > Py_UnicodeFlag).  It can't occur later, because you need to skip the
> > encoding being done in parsestr().  But the __future__ import can only
> > be interpreted after the AST is built, at which time the encoding has
> > already been applied.  There are some radical things you could do to
> > work around this, but it would be a gigantic change.
>
> Oh, <swear words>!
>

I don't believe this to be true (we can simply store the source encoding
information (which it might already be) and translate the *use* of string
literals into unicode(literal, encoding).) But I still think this is a bad
idea. Using the same codebase for 3.0 and 2.6 will leave you with
inefficient and fragile code in one of the two codebases -- quite likely
both. I know, I've tried. I don't see how it improves maintainability to
leave your source full of forward- and backward-compatibility hacks. 3.0 was
meant to be a clean break. Please treat it as such. Yes, that means you
can't run the same source tree in two different Python versions -- too bad.
It means adding a compilation-style step to one of the two Python versions
-- too bad. It's quite easily automated, as proven by the vast majority of
programming languages out there, which need such a step anyway.


>
> Howver: If 2.6 doesn't support this it's not the end of the world.
> Because if it turn out to be necessary, a 2.7 that does could always
> be released. I don't know about other large codebases like Twisted,
> but the Zope/Plone world isn't likely to  even try moving to 3.0 any
> time soon after it's final release, so since it's complicated you can
> probably wait with this support until it turns out to be needed.
>

That was always the assumption, and also the idea for 2.6 and 2.7. I would
much rather 3.0 isn't widely accepted for a few years longer than that it be
cluttered with backward compatibility crap, and even rather than that widely
used code be riddled with such. But it's up to Guido in the end.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080323/46de93c9/attachment.htm