[Python-Dev] PEP 264

[Tim Peters]

[Michael Hudson]
> Thank you in turn for fixing all my cock-ups!

There were few -- it turned out to take much longer than "it should have"
for reasons I don't want to bother recounting now, but rest assured there
was plenty of blame to go around.  Not nearly so much blame as glory, though
<wink>.

> I'd just like to note in passing that I considered most of the places
> the CO_* constants ended up in the last week, and rejected them as too
> gross.  My idea was that
>
> __future__.generators.compiler_flag
>
> was to be the *only* (Python) name for CO_GENERATORS_ALLOWED (for
> example).  Are there problems with this (other than the fact that you
> have to make sure two sets of magic numbers match up - but you have to
> edit __future__.py when you add a new future feature anyway...).

The problem is that nobody is going to *remember* the subtleties.  IIRC,
almost every bug I tracked down was due to *someone* neglecting to fiddle
all the places that needed to be fiddled when changing future-flags.  So The
Rule I implemented was two-fold:

1. If possible, remove the need to remember at all (e.g., that was
   done for PyEval_MergeCompilerFlags, which hadn't been updated to
   know about CO_FUTURE_DIVISION (a bug), but was still uselessly
   merging CO_NESTED (a waste)).

2. When not possible, guarantee that a dumb-ass global editor search
   will find all "conceptual" uses of a CO_xxx flag name.

#2 is why __future__.py contains the names "CO_NESTED" etc.  Since it's not
possible to hide the need entirely, it's imperative to make the dumbest
approach imaginable likely to succeed for the next time, when the novelty
has warn off and nobody quite remembers anymore exactly what needs to be
done.  pyassem.py (in the Compiler package) does the same thing.

> I should probably add some words to the PEP on this topic, anyway.

I don't think it's needed; at this point the bugs have all been shamed into
good behavior by the relentless application of simple good taste <wink>.