"Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
> "Ron Garret" <[EMAIL PROTECTED]> wrote: > > > > I don't want to get into a philosophical debate. > > > > Actually, I changed my mind. Consider: so did I - I think the chair analogy is not quite clear, so let me elucidate: > > > > def g(): print 'G' > > > > def h(): print 'H' > > > > def f(): g() > > > > class C1: > > def m1(self): f() up to here: m1 will call f that will call g - should there ever be an m1 of this class > > > > class C2: > > def m1(self): g() the m1 of this class will call g with no redirection, if it were called into existence and called > > > > c1 = C1() > > c2 = C2() two new things are made (chairs?) , called c1 and c2- so at this point, c1.m1() #Prints G c2.m1() #Prints G as expected > > > > def f(): h() now f is changed to call h instead of g for future calls to f (- loose talk this - actually the name f is rebound...) > > > > class C2: > > def m1(self): h() this is just a promise of things to come, if an instance of this new class with the old name should be made... > > > > c1.m1() # Prints H > > c2.m1() # Prints G yup. > > > > On what principled basis can you justify two different outputs in this > > case? Why should I be able to change the definition of f and not have > > to go back and recompile all references to it, but not m1? 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 -- http://mail.python.org/mailman/listinfo/python-list