Fw: Is there a reason not to do this?

[Hendrik van Rooyen]

so did I - I think the chair analogy is not quite clear, so let me elucidate:

up to here:

m1 will call f that will call g - should there ever be an m1 of this class

the m1 of this class will call g with no redirection, if it were called into
existence and called

two new things are made (chairs?) , called c1 and c2-
so at this point,

c1.m1() #Prints G
c2.m1() #Prints G

as expected

now f is changed to call h instead of g for future calls to f (- loose talk
this - actually the name f is rebound...)

this is just a promise of things to come, if an instance of this new class with
the old name should be made...

yup.

I think the simplest way to look at this is as follows - the inherited
"attributes" of a class instance are "fixed"
at the time of instantiation, while the function redirection works because it is
evaluated at the time that it is called, not at the time it is created (or
defined if you prefer).

To make it work the way you want, would, I expect, require that the whole
instantiation process be either checked for validity, or executed with every
call to a class instance - a sort of make and kill on the fly process, or
alternatively, at the time of the re definiton of a class, all instances of the
class of that name would have to be re initialised - and this may not be
possible, if for instance, the new __init__ method needs more variables than the
old one did - so it becomes a bit of a toffee, and it looks as if the python dev
crowd wisely decided to just leave it alone...

This feels to me as if you are changing the specification of what wood to use
from yellowood to teak after the chair has already been made.

so now maybe you can see why I said that. ;-)

- Hendrik