[Python-Dev] Backporting PEP 414

Nick Coghlan ncoghlan at gmail.com
Wed Feb 29 00:25:52 CET 2012


On Wed, Feb 29, 2012 at 8:17 AM, Chris McDonough <chrism at plope.com> wrote:
> But yeah.  A year from now I wouldn't remember which version of 3.2 got
> a new feature, and neither would anybody else.  The no-new-features
> guidelines are useful in the real world this way, because they represent
> a coherent policy, as tempting as it is to just jam it in.

Also, I think there may be some confusion about Armin's plan to handle
3.2 - he aims to write an *import hook* that accepts the u/U prefixes
during tokenisation, not a source-to-source transform like 2to3. It's
clumsier than the plan for native syntactic support in 3.3 (since
you'll need to make sure the import hook is installed, the presence of
the hook will add overhead during application startup, and any
attempts to compile affected modules that don't go through the import
machinery will fail with a syntax error), but the presence of
importlib in 3.2 makes it quite feasible. When loading from a cached
.pyc, the hook won't even have to do anything special (since the
tokenisation change only affects the compilation step).

Assuming Armin can get the hook working as intended, then long running
applications where startup overhead isn't a big deal will just need to
ensure the hook is in place before they import any modules that use
the old-style string literals. For cases where the startup overhead
isn't acceptable (such as command line applications), then approaches
that change the source in advance (i.e. separate branches or single
source with the unicode_literals future import) will continue to be
the preferred mechanism for providing 3.2 support.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list