new.instancemethod

[Alex Martelli]

<James_Althoff at i2.com> wrote in message
news:mailman.990208409.8727.python-list at python.org...
    ...
> I guess I'm a just an "old school" (well, *old* for sure) class-centered
> person.  The thing that I really like about the approach below is that --
> assuming that the example is modified slightly so that the class "Tweak"
is
> pulled out of the function definition and is available in the module -- I

...then class 'Tweak' will have ONE base class, rather than the variety
of specific base classes it will need for this use:

> >def tweak_ownbid(obj):
> >    Base = obj.__class__
> >    class Tweak(Base):
> >        Base = Base

If I need to change obj's __class__, it's important that I do so _to a
class inheriting from its previous value_, else I might lose some kinds
of personalizations already done to an object regarding other methods.

The class statement does need to be executed separately for each
object being 'specialized' or 'tweaked'.  Or you might build a new
class on the fly with module new, of course, but that's a murkier
approach than a simple class statement, it seems to me.

> could then define a second "instance-specific subclass" and have that one
> use "Tweak" as a base class and reuse (tweak?) the Tweak.ownbid method.

You can do that without exposing the NAME 'Tweak' -- you'll just
inherit from obj.__class__ in the other subclass too, and keep
"stacking" classes this way.  But note that setting instance specific
methods isn't substantially different either, you just need to save
somewhere in the object the method you're "overriding" if you want
to make calls back to it -- probably, with Python 2.1, function
attributes are the ideal place for that (as long as the def statement
is also re-executed, like class needs to be above, to give you a
new function object each time).

In the end the architectures are pretty close, but it looks to me
as if the method-based one is 'slimmer' for a class with a LOT of
methods, as a bridge-hand class might need.  If we have, say,
60 methods, and each is 'specialized' a couple times, then in
one case we have a 'chain' of length about 2 on each method,
in the other a huge 'chain' of over 100 classes that needs to
be walked-up to find methods.  Maybe it makes no real difference,
but it 'feels' slimmer the first way.

> Although you might not always need such reuse, I really like the ability
to
> extend things in the future by taking advantage of the "framework for
> reuse" that a class gives you -- even if a class only has a singleton
> instance.  That's one of the big reasons I really like methods in a class
> compared to functions outside of a class (because you can override the
> method, call the super class method, add some behavior, etc. -- damn the
> "fragile base classes", full speed ahead! ;-)).

But I do that in method-based personalization of instances, too.

Indeed I find it easier to compose personalizations because I do
not have to worry about what's happening to OTHER methods --
changing some tweaks in bidding strategy need not worry about
lead strategy or signaling or...  Or I may change the priority of
checks for two tweaks by reordering the 'chains' per-method more
easily than I can do with the chains of class inheritance...


> Anyway, I really like the example below.  Creating a subclass on the fly
> and then changing the __class__ of an instance -- if used judiciously --
> seems like a really useful approach for instance-specific behavior in
> certain cases.  Thanks, Alex.

You're welcome, but I think we should all thank Guido for putting this
stuff in the language in the first place:-).  "Judiciously" is a keyword
here I think -- it's great for experimental interactive specialized
programming frameworks, but I can't think of a case I would WANT
to use such black magic in _production_ code.


Alex