[Python-Dev] Proposal: from __future__ import unicode_string_literals
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
That approach appears to be a lot easier to implement than trying
to tweak the C implementation of the Python parser.
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