[Python-Dev] PEP 264 (was RE: [Python-checkins] CVS: python/nondist/peps pep-0264.txt,NONE,1.1 pep-0000.txt,1.113,1.114)

[Tim Peters]

[Guido, checking in
    Michael Hudson's "Future statements in simulated shells".
 PEP
]
> ...
>     Paul Prescod has reasonably complained about the choice of a
>     bitfield as the fourth argument to compile(), claiming it is
>     obscure and unpythonic.

I've got a happy idea!  __future__.py is a real std module, and e.g.

    __future__.nested_scopes
    __future__.generators
    __future__.division

are honest-to-gosh Python objects, of class __future__._Feature.  That's the
perfect place to store feature-specific magic flag bits.  So, e.g., I'm
picturing

    compile(s1, s2, s3, __future__.generators.getflag())

and

    flags = 0
    for fname in list_of_feature_names:
        flags |= getattr(__future__, fname).getflag()
    compile(s1, s2, s3, flags)

etc.  For that matter, list-of-feature-strings -> flag_bits could be added
as a utility function to __future__.py.  It's Python -- there's nothing you
can't do with this in 5 seconds <wink>.