[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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4