[Python-Dev] Changing existing class instances

[Guido van Rossum]

> From: "Tim Peters" <tim_one@email.msn.com>
> 
> [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/)