Hi. [Tim Peters] > > 2. How should the interactive interpreter be handled? > > You're kidding. I thought we agreed to drop the interactive interpreter for > 2.1? (Let's *really* give 'em something to carp about ...) > > > I presume if you type > > >>> from __future__ import nested_scopes > > > > That everything thereafter will be compiled with nested scopes. > > That's my guess too, of course. > > > This ends up being a little tricky, because the interpreter has to > > hang onto this information and tell the compiler about it. > > Ditto for > > python -i some_script.py This make sense but I guess people will ask for a way to disable the feature after a while in the session, even trickier. > where some_script.py contains a magical import. OTOH, does exec-compiled > (or execfile-ed) code start with a clean slate, or inherent the setting of > the module from which it's exec[file]'ed? I think the latter has to be > true. I disagree, although this reduces the number of places where one has to delete from __future__ import when _future_ is here, for some uses of execfile the original program has just little control over what is in the executed file I guess, better having people being explicit there about what they want. And this way we don't have to invent a way for forcing disabling the feature (at least not because of the inherited default problems). exec should not be that different. Or we need an even more complicated mechanismus? like your proposed import not. regards, Samuele Pedroni.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4