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