[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.