Nested Scopes in Idle/PythonWin

[Tim Peters]

[Michael Hudson]

[bytecodehacks suppressed to protect the innocent <wink>]

> ...
> Fourth (optional) argument to __builtin__.compile, anyone?  I'd submit
> a patch to code{,op}.py but if nested scopes are going to be the
> default in 2.2 there ain't a lot of point.

This has much less to do with nested scopes than with PEP 236's *real* topic:
dealing with incompatible language changes during a transition period.
Nested scopes is just the first example of that, and the same problems will
reoccur, mutatis mutandis, if any other gimmick ever falls unders this
mechanism (and whether it's spelled "__future__" or "directive transitional"
or "up yours" or ...).

> Bah.  This is annoyingly crap, I'm afraid.  I wish I'd known about
> this before 2.1 went out.

You should read every PEP cover to cover every day <wink>.

For nested scopes I didn't consider this to be more than a minor nuisance at
worst:  I simply won't type gobs of nested functions directly to a shell
prompt anyway.  I've played with nested scopes a *lot* in IDLE, but in a sane
way:  put my temp code in an IDLE edit window, with a future statement at the
top, then use IDLE's "Run Script" to run it and show the results in the shell
window.

This is easy.  It could be unbearable for *other* kinds of incompatible
changes, though.  For example, if

    1/2

is changed to mean 0.5, then we definitely need to solve IDLE's (and
PythonWin's, and PythonWorks's, and Emacs Python-process buffer's, and ...)
simulated shell problems here.

So there's not a rush, and it needs a clean solution.  For example,
codeop.py's compile_command could grow an optional list of "feature name"
arguments, and then when compile_command decides a command is complete,
recompile it with those future-features in effect.  It probably doesn't need
hacks at the bytecode level -- and the front-end simulated shells don't work
at that level anyway (all *they* can do is recognize future statements when
they appear, remember the names of the future features in a "sticky list" of
strings, and pass them on to whatever they're using that eventually calls
compile_command).

More convenient for everyone may be an API telling the compiler "OK, assume
these future-features until somebody tells you to stop assuming them".  Then
we get the joy of managing hidden global state across uncooperative modules
<wink>.