Is there a reason not to do this?

Ron Garret rNOSPAMon at flownet.com
Fri Dec 1 02:44:52 EST 2006


In article <rNOSPAMon-ACA0D1.23364830112006 at news.gha.chartermi.net>,
 Ron Garret <rNOSPAMon at flownet.com> wrote:

> In article <mailman.916.1164955848.32031.python-list at python.org>,
>  "Hendrik van Rooyen" <mail at microcorp.co.za> wrote:
> 
> >  "Ron Garret" <rNOSPAMon at flownet.com> wrote:
> > 
> > 
> > >
> > > One of the things I find annoying about Python is that when you make a
> > > change to a method definition that change is not reflected in existing
> > > instances of a class (because you're really defining a new class when
> > > you reload a class definition, not actually redefining it).  So I came
> > > up with this programming style:
> > 
> > I would have thought that not changing yesterday was the very essence of
> > dynamism (dynamicness ??) - but that when you change something - it applies 
> > from that point in time forwards...
> 
> I don't want to get into a philosophical debate.

Actually, I changed my mind.  Consider:

def g(): print 'G'

def h(): print 'H'

def f(): g()

class C1:
  def m1(self): f()

class C2:
  def m1(self): g()

c1 = C1()
c2 = C2()

def f(): h()

class C2:
  def m1(self): h()

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

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?

rg



More information about the Python-list mailing list