Oh man, oh man... I think this is where I get to say something akin to "I told you so." :-) I already described Tim's proposal in my type proposal paper, as a way to deal with incomplete classes. Essentially, a class object is created "empty" and is later "updated" with the correct bits. The empty class allows two classes to refer to each other in the "recursive type" scenario. In other words, I definitely would support a new class object behavior that allows us to update a class' set of bases and dictionary on the fly. This could then be used to support my solution for the recursive type scenario (which, in turn, means that we don't have to introduce Yet Another Namespace into Python to hold type names). Note: I would agree with Guido, however, on the "look for a class object with the same name", but with the restriction that the name is only replaced in the *target* namespace. i.e. a "class Foo" in a function will only look for Foo in the function's local namespace; it would not overwrite a class in the global space, nor would it overwrite class objects returned by a prior invocation of the function. Cheers, -g On Thu, 20 Jan 2000, Tim Peters wrote:
[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.
Modules differ because their namespace "search path" consists solely of the more-global-than-global <wink> sys.modules.
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. 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>.
(Your extra indirection also slows things down, although I don't know by how much -- not just the extra memory reference but also less locality of reference so more cache hits.)
Across the universe of all Python programs on all platforms, weighted by importance, it was a slowdown of nearly 4.317%.
if-i-had-used-only-one-digit-everyone-would-have- known-i-was-making-it-up<wink>-ly y'rs - tim
_______________________________________________ Python-Dev maillist - Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev
-- Greg Stein, http://www.lyra.org/