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():
Since we are in a hackish mood, another alternative - interesting if
you want
the freedom to update your instances selectively - is to change their
class at
runtime.
In this way you can specify which instances must use the new version of
the class and which ones must keep the old one. It may be
Ron Garret wrote:
Doesn't work for me:
c2
__main__.C2 instance at 0x51e850
c2.m1()
G
class C2:
... __metaclass__ = modify_in_place
... def m1(self): print 'Q'
...
c2.m1()
G
C2().m1()
Q
I assume your original C2 class was defined in a different module, not
in the current
Ron Garret 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
Ron Garret [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
These objects can be parts of huge networks of massively linked data
structures. They are in constant flux. It is not uncommon to hit a bug
after many minutes, sometimes hours, of computation. Having to store
the whole
Ron Garret wrote:
In article [EMAIL PROTECTED],
Ron Garret [EMAIL PROTECTED] wrote:
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):
In article [EMAIL PROTECTED],
Carl Banks [EMAIL PROTECTED] wrote:
The principle behind this is pretty much it was just a language design
decision.
Yes, and I'm not taking issue with the decision, just pointing out that
the desire to do things differently is not necessarily perverse.
P.S.
In article [EMAIL PROTECTED],
Michele Simionato [EMAIL PROTECTED] wrote:
Ron Garret 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
Ron Garret [EMAIL PROTECTED] wrote:
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
with this programming style:
def defmethod(cls):
return lambda (func): type.__setattr__(cls, func.func_name, func)
class c1(object): pass
@defmethod(c1)
def m1(self, x): ...
Now if you redefine m1, existing instances of c1 will see the change.
My question is: is there a reason not to do this? Does
is: is there a reason not to do this? Does it screw
something up behind the scenes? Is it unpythonic? Why isn't this
standard operating procedure?
What are you doing that needs this permanent redefinition? I like the
repl, yet usually - especially when dealing with classes - I write a
text file
): ...
Now if you redefine m1, existing instances of c1 will see the change.
My question is: is there a reason not to do this? Does it screw
something up behind the scenes? Is it unpythonic? Why isn't this
standard operating procedure?
What are you doing that needs this permanent
)
def m1(self, x): ...
Now if you redefine m1, existing instances of c1 will see the change.
My question is: is there a reason not to do this? Does it screw
something up behind the scenes? Is it unpythonic? Why isn't this
standard operating procedure?
1. Do you mean
Carl Banks [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
A straightforward, Pythonic way to do it would be to create an
intermediate representation that understands both the existing class
interfaces and the RDB stuff, but that could lead to synchronizing
problems and a big hit
In article [EMAIL PROTECTED],
Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Ron Garret [EMAIL PROTECTED] 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
In article [EMAIL PROTECTED],
Ron Garret [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Ron Garret [EMAIL PROTECTED] wrote:
One of the things I find annoying about Python is that when you make a
change to a method
In article [EMAIL PROTECTED],
Paul McGuire [EMAIL PROTECTED] wrote:
Carl Banks [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
A straightforward, Pythonic way to do it would be to create an
intermediate representation that understands both the existing class
interfaces and
17 matches
Mail list logo
