This is a patch that modifies the parser to allow getting the future
import flags into the AST. There are 2 approaches that are embedded
within the patch. Both approaches can be seen in Python/pythonrun.c.

1. update_flags_from_node() - this pulls the __future__ import out of
   the parser nodes. It is not complete, but should give an idea of how
   this approach could be generalized.
2. Add APIS such as PyParser_ParseFileFlagsEx that returns the flags
   from the parser

The first approach is somewhat fragile and kinda breaks encapsulation.
It's nice that all the changes are internal and localized.

The second approach is probably a better long term solution, but adds
even more APIs where there are already too many.

I'll check it out today.

I've carefully examined both version. I agree that
update_flags_from_node is too fragile. I haven't verified my theory but
I *think* the current code does neither support

  from __future__ import egg, spam

nor

  from __future__ import egg
  from __future__ import spam

The PyParser_ParseFileFlagsEx() is easier and more stable. I'll go with it.

By the way I also like your name "unicode_strings". Should we stay with
it or use my idea "unicode_literals"?

The flag should be named "unicode_literals" since that what changes.
Unicode strings are already available in Python 2.x :-)

BTW: I'm not convinced that these future imports are all that useful -
the ratio between usefulness and added complexity leans a lot towards
the latter.

Working patch

I had to introduce yet another PyParser Ex method for string parsing. I
also renamed the future feature to "unicode_literals"

The patch actually isn't all that complicated - the main structural
change to make it possible to process the strings correctly is
converting the parser functions to have treat the flags argument as an
I/O variable, rather than just an input. Other than that, there are just
some fairly straightforward updates to the compiler to take advantage of
the additional flag information now available from the parser.

Being able to write significant pieces of code that run on both 2.6 and
3.0 without modification will be a big win in my opinion. While 2to3
will still be a valuable migration tool, especially for one-way
migrations, it will be far far easier to support 2.6 and 3.0 in parallel
if that pseudo-compilation step isn't necessary.

Also Christian - the posted patch accidentally included your hack to
make the version info a bit more non-SVN checkout friendly.

Also Christian - the posted patch accidentally included your hack to
make the version info a bit more non-SVN checkout friendly.

I'm still learning bzr. I just have figured out how to merge changes
from the upstream trunk into my branch. It's actually nice ...

Slightly better patch

• removed bzr hack
• simplified parsestr()
• updated NEWS

Christian checked this in a few days ago in r61953 and a few other
revisions.