[Python-Dev] Changing existing class instances

[Tim Peters]

[Tim, still worried about stomping on unintended classes/defs]

[example abusing Tkinter.Misc]

> For a second I thought you got me there!

That's twice as long as I thought you'd think that, so I win after all
<wink>.

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

OK!  I didn't know about class.__module__ -- I hope you realize that relying
on your time machine is making you lazy <wink>.

I remain uncomfortable with automagic updating, but not as much so.  Both
kinds of errors still seem possible to me:

1. Automagically updating when it wasn't wanted.

Examples of this are getting harder to come by <wink>.  Off the top of my
head I'm reduced to stuff like this:

>>> adders = []
>>> for i in range(10):
	def adder(y, x=i):
		return y+x
	adders.append(adder)


>>> adders[2](40)
42
>>> adders[9](33)
42
>>>

"That kind of thing" has got to be rare, but can't be non-existent either
(well, isn't -- I've done it).

2. Failing to automagically update when it was wanted.

Implicit in the discussion so far is that long-running systems want to
update code at a granularity no finer than module level.  Is that realistic?
I'm unsure.  It's certainly easy to *imagine* the app running an updater
server thread, accepting new source for functions and classes, and offering
to compile and install the objects.

Under the explicit new.update scheme, such a service needn't bother clients
with communicating the full name of the original module; heck, in a *truly*
long-running app, over time the source tree will change, and classes and
functions will migrate across modules.  That will be a problem for the
explicit scheme too (how does it know *which* "class Misc" to update) -- but
at least it's an explicit problem then, and not a "mysterous failure" of
hidden magic.


I could live with both of those (#1 is more worrisome); but think it easier
all around to give the users some tools and tell them to solve the problems
however they see fit.

or-maybe-we-already-agreed-about-that-ly y'rs  - tim