From: "Tim Peters"
[Guido, on Andrew's idea for automagically updating classes]
There might be another solution. When you reload a module, the module object and its dictionary are reused.
Perhaps class and function objects could similarly be reused? It would mean that a class or def statement looks for an existing object with the same name and type, and overwrites that. Voila, all references are automatically updated.
Too dangerous, I think. While uncommon in general, I've certainly seen (even written) functions that e.g. return a contained def or class. The intent in such cases is very much to create distinct defs or classes (despite having the same names). In this case I assume "the same name" wouldn't *usually* be found, since the "contained def or class"'s name is local to the containing function. But if there ever happened to be a module-level function or class of the same name, brrrr.
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.
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."
This is more work (e.g. for classes, a new bytecode may have to be invented because the class creation process must be done differently) but it's much less of a hack, and I think it would be more reliable. (Even though it alters borderline semantics a bit.)
How about an explicit function in the "new" module,
new.update(class_or_def_old, class_or_def_new)
which overwrites old's guts with new's guts (in analogy with dict.update)? Then no semantics change and you don't need new bytecodes.
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. If you make all these assignable, it doesn't even have to be a privileged function.
In return, a user who wants to e.g. replace an existing class C would need to do
oldC = C do whatever they do to get the new C new.update(oldC, C)
Building on that, a short Python loop could do the magic for every class and function in a module; and building on *that*, a short "updating import" function could be written in Python. View it as providing mechanism instead of policy <0.9 wink>.
That's certainly a reasonable compromise. Note that the update on a class should imply an update on its methods, right? --Guido van Rossum (home page: http://www.python.org/~guido/)