[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)
08 Aug 2001 17:54:50 -0400
Instant response, without that tedious-prone-to-problem-spotting
thinking: nice idea!
"Tim Peters" <email@example.com> writes:
> [Guido, checking in
> Michael Hudson's "Future statements in simulated shells".
> > ...
> > 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.
> 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
> compile(s1, s2, s3, __future__.generators.getflag())
> 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>.
"list_of_feature_names" might as well be spelt "__future__.__all__",
I'd have thought.
There's still the icky issue of PyEval_MergeCompilerFlags to consider.
The fact that each future statement has two bits assigned to in - the
PyCF_* ones in pythonrun.h and the CO_* ones in compile.h that allow
__builtin__.compile to inherit the behaviour of surrounding code -
seems nasty. We could just mandate that
CO_FOO == PyCF_FOO << 12
Or add another flag to code objects. Or do something else.
The possibility of fiddling with __future__.py had completely escaped
my mind - so thanks for pointing me at that!
If you don't use emacs, you're a pathetic, mewling, masochistic
weakling and I can't be bothered to convert you. -- Ron Echeverri