[Python-Dev] Proposal: from __future__ import unicode_string_literals

M.-A. Lemburg mal at egenix.com
Fri Mar 21 22:35:47 CET 2008

On 2008-03-21 22:32, Martin v. Löwis 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.  
> I think it would be possible to check for future statements on the
> basis of nodes already. Take a look at how Python 2.3 implemented
> future statements (why was that rewritten to use the AST, anyway?).
>> As for it not making sense, this is really in the realm of 2to3.  I'm 
>> beginning to really believe this statement in PEP 3000:
> There is still the original use case of people who don't want to run
> 2to3 (for whatever reasons - mostly probably subjective ones), and
> who would rather run a single code base unmodified. They don't care
> that documentation tells them this is impossible, when they feel they
> are so close to making it possible.

Could we point them to a special byte-code compiler such as Andrew
Dalke's python4ply:


That approach appears to be a lot easier to implement than trying
to tweak the C implementation of the Python parser.

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Mar 21 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Python-Dev mailing list