> [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). For a second I thought you got me there! > 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). Fortunately, there's magic available: recently, all classes have a __module__ attribute that is set to the full name of the module that defined it (its key in __sys__.modules). For functions, we would have to invent something similar. > >> 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 --Guido van Rossum (home page: http://www.python.org/~guido/)
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