[Python-Dev] Changing existing class instances

[Greg Stein]

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/