[Python-Dev] Proposal: from __future__ import unicode_string_literals

[Lennart Regebro]

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>!

> Pretty much.  And even if it were possible, I don't see the point in
> doing it.

The point is this:
http://regebro.wordpress.com/2008/03/22/why-python-26-and-30-compatibility-would-be-a-very-good-thing/

Basically, the 2to3 strategy on large codebases supported by a wide
set of developers isn't likely to be maintanable, and without a
gradual path forward, 3.0 isn't likely to be adopted in some parts of
the Python community. Worst case this splits the efforts of the
community into two groups, which would be damaging to Python as a
whole.

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.

M.-A. Lemburg wrote:
> Could we point them to a special byte-code compiler such as Andrew
> Dalke's python4ply:

??? I'm not sure what this means... :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64