[Python-Dev] Changing existing class instances

[Tim Peters]

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

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).

>> 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