[Python-Dev] Changing existing class instances

[Guido van Rossum]

> [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/)