One Python 2.1 idea

[Moshe Zadka]

[Moshe asks for problem where changing __class__ would be useful]

[Alex explains...snipped for brevity]
> Now, consider a "plug-in" that is transiently activated; when
> it IS active, it wants to "tweak" the behavior of just a few,
> specifically-identified 'buttons' (&c) and 'internal objects'
> out of the zillion instances of those classes that exist at
> any given time in the GUI and in the internal engine.
....
> the 'affected' object
> must revert to 'normal behavior' if the plug-in is deactivated,
> as well as keeping normal behavior for a h**l of a lot of other
> methods.
...
> The simplest way to frame this, is to tell the plug-in authors
> that they can just substitute their own code for any given
> subset of methods of any exposed objects they can identify,
> and 'restore' the original behavior when needed.
[Ed. -- Other solution is to implement half of common lisp yourself]

Wow, Alex, I must say the length and patience of your posts amazes
me each time. Now I know I'll never be a bot.

I must say that in this case, I'm *sure* I'd fiddle with __class__
rather then the new module. It's simple more obvious to write:

class SuperSpline(Spline):

	def distort_shape(self):
		pass
...

get_selected_spline().__class__ = SuperSpline

# deactivate
for object in get_all_objects():
	if object.__class__ is SuperSpline:
		object.__class__ = object.__class__.__bases__[0]


Seems super-obvious.
Of course, in that case, you know the original class very well.

for-weird-enough-definitions-of-obviousness-ly y'rs, Z.
-- 
Moshe Zadka <sig at zadka.site.co.il>
This is a signature anti-virus. 
Please stop the spread of signature viruses!