[Python-Dev] Backporting PEP 414 (original) (raw)

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