Fw: Is there a reason not to do this?

[Hendrik van Rooyen]

"Hendrik van Rooyen" <mail at microcorp.co.za> wrote:


> "Ron Garret" <rNOSPAMon at flownet.com> 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