[Tim worries about stomping on unintended classes/defs] [Guido]
Agreed that that would be bad. But I wouldn't search outer scopes -- I would only look for a class/def that I was about to stomp on.
Maybe I just don't grasp what that means, exactly. Fair enough, since I'm not expressing myself clearly either! Suppose someone does from Tkinter import * in my.py, and later in my.py just *happens* to define, at module level, class Misc: blah blah blah Now Misc was already in my.py's global namespace because Tkinter.py just happens to export a class of that name too (more by accident than design -- but accidents are what I'm most worried about here). At the time my.py defines Misc, does Misc count as a class we're "about to stomp on"? If so-- & I've assumed so --it would wreak havoc. But if not, I don't see how this case can be reliably distinguished "by magic" from the cases where update is desired (if people are doing dynamic updates to a long-running program, a new version of a class can come from anywhere, so nothing like original file name or line number can distinguish correctly either).
Modules differ because their namespace "search path" consists solely of the more-global-than-global <wink> sys.modules.
"The search path doesn't enter into it."
I agree, but am at a loss to describe what's happening in the case above using other terminology <wink>. In a sense, you need a system-wide "unique handle" to support bulletproof updating, and while sys.modules has supplied that all along for module objects (in the form of the module name), I don't believe there's anything analogous to key off of for function or class objects.
[suggesting] new.update(class_or_def_old, class_or_def_new)
Only a slight semantics change (which my full proposal would require too): function objects would become mutable -- their func_code, func_defaults, func_doc and func_globals fields (and, why not, func_name too) should be changeable.
Of course I meant "no new semantics" in the sense of "won't cause current exception-free code to alter behavior in any way".
If you make all these assignable, it doesn't even have to be a privileged function.
I'm all for that!
[sketching a Python approach to "updating import/reload" building on the hypothetical new.update]
That's certainly a reasonable compromise. Note that the update on a class should imply an update on its methods, right?
Hadn't considered that! Of course you're right. So make it a pair of nested loops <wink>. so-long-as-it-can-be-written-in-python-it's-easy-ly y'rs - tim