Movatterモバイル変換
[0]ホーム
Nested Scopes in Idle/PythonWin
Tim Peterstim.one at home.com
Sun Apr 22 19:51:14 EDT 2001
[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 willreoccur, mutatis mutandis, if any other gimmick ever falls unders thismechanism (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 atworst: I simply won't type gobs of nested functions directly to a shellprompt anyway. I've played with nested scopes a *lot* in IDLE, but in a saneway: put my temp code in an IDLE edit window, with a future statement at thetop, then use IDLE's "Run Script" to run it and show the results in the shellwindow.This is easy. It could be unbearable for *other* kinds of incompatiblechanges, though. For example, if 1/2is changed to mean 0.5, then we definitely need to solve IDLE's (andPythonWin'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 needhacks at the bytecode level -- and the front-end simulated shells don't workat that level anyway (all *they* can do is recognize future statements whenthey appear, remember the names of the future features in a "sticky list" ofstrings, and pass them on to whatever they're using that eventually callscompile_command).More convenient for everyone may be an API telling the compiler "OK, assumethese future-features until somebody tells you to stop assuming them". Thenwe get the joy of managing hidden global state across uncooperative modules<wink>.
More information about the Python-listmailing list
[8]ページ先頭