Draft PEP (RE: Other situations like this (was RE: [Python-Dev] Nested scopes resolution -- you can breathe again!))

[Tim Peters]

[Tim]
>> Code emulating module imports is rare.  People writing such
>> mechanisms had better be experts!  I don't want to warp the
>> normal case to cater to a handful of deep-magic propeller-heads
>> (they can take care of themselves).

[Guido]
> OK.  I'm not completely convinced, but at least 60%, and that's
> enough.

Oh, I'm not convinced either.  But eval/exec/compile/input/execfile are rare
operations (in frequency of occurrence per Kline of code), and I don't want
that very tangled tail wagging this dog.  I don't think either of us will be
wholly convinced in either direction without feedback from the beta.

I *have* convinced myself tabnanny will work <wink>.  But not doctest.
doctest basically simulates an interactive shell session one statement at a
time, and a new shell session for each docstring (not stmt).  My mind simply
boggles at imagining all the extra machinery that would need to be in place
to make that "work" in all conceivable cases.  The __future__ choices
doctest itself makes should have no effects on the code it's simulating, but
the code it's simulating *should* be affected by the __future__ choices of
the module passed to doctest.testmod(); so, at a minimum, it would appear to
require a standard way to query a module object for its set of __future__
choices, and an additional argument to compile() allowing to force that set
of choices, *and* a way for doctest to tell compile() "oh, ya, if you happen
to compile a __future__ statement, and I later execute the code you
compiled, make that persist until I tell you to stop" (else simulated
__future__ statements won't work as expected).

Perhaps those are widespread needs too, but, I doubt it, and I don't think
we need to solve the entire problem today regardless.