[Python-Dev] Changing the Division Operator -- PEP 238, rev 1.12
Fri, 10 Aug 2001 17:18:14 -0400
Man, I'm having a hard time following this! Perhaps people are talking
passed each other?
> It's a matter of interface, really. It's certainly not at all
> technically hard. Maybe:
> compile(text, filename, symbol[, flags[, dont_inherit]])
Sounds good -- let's do it.
> I worry that saying "you don't inherit behaviour from surrounding code
> as soon as you pass a flag" might get really, really confusing at
I would too, but did someone suggest that? Not me. If someone did, they're
confusing issues to no good end.
> Occam sez: let's add the dont_inherit argument when we have found a
> real use for it.
It's trivial to add, impossible to work around its absence if necessary, and
is an inherent part of the problem space (as Michael said, the future-PEP
anticipated the problem). It seems as simple as possible without leaving
> There are two complementary sets of flags here:
> (1) The PyCF_* ones, defined in Include/pythonrun.h
> (2) The CO_* ones defined in Include/compile.h
> The proposed fourth argument to compile() should be a combination of
> the former set.
> I only use the latter to tell whether a __future__ statement was used
> in the text compiled (which is a bit horrible, but no better way
> springs to mind).
If there were a better way, we would have used it instead of the goofy CO_*
flags everywhere else too <wink>.
> There might be value in checking the flags passed to compile() anyway,
> but I can't see it being dangerous.
It's so easy to make this bulletproof that there's no point discussing
whether it *should* be made bulletproof. I'll see to it that it's
bulletproof in the end, so if it's a hangup don't worry about it now.
> (I think I may have been confused by your original patch, which AFAICR
> manipulate the co_flags field of the code object, which contains the CO_*
Right, it did, and the newer scheme is safer.