Gabriel Genellina wrote:
I see.
Then is there a reason why
return super(Subclass, self).parrot()
would be prefered over the "classic"
return Base.parrot(self)
?
Or is it just a matter of preference ?
For a longer explanation, see:
James Knight: Python's Super Considered Harmful
http://fuhm
En Mon, 18 Jan 2010 16:50:45 -0300, Jean-Michel Pichavant
escribió:
Duncan Booth wrote:
Jean-Michel Pichavant wrote:
class SubClass(Base):
colour = "Red"
def parrot(self):
"""docstring for Subclass"""
return super(Subclass, self).parrot()
I'm not a big fan of supe
Jean-Michel Pichavant writes:
[...]
> Then is there a reason why
return super(Subclass, self).parrot()
> would be prefered over the "classic"
return Base.parrot(self)
> ?
>
> Or is it just a matter of preference ?
Using super() calls the next method in the class's Method Resolution
O
Duncan Booth wrote:
Jean-Michel Pichavant wrote:
class SubClass(Base):
colour = "Red"
def parrot(self):
"""docstring for Subclass"""
return super(Subclass, self).parrot()
I'm not a big fan of super, but I'm still wondering if
return super(self.__cl
Jean-Michel Pichavant wrote:
>
class SubClass(Base):
colour = "Red"
def parrot(self):
"""docstring for Subclass"""
return super(Subclass, self).parrot()
> I'm not a big fan of super, but I'm still wondering if
>
> >>> return super(self.__class__,
On Jan 1, 12:11 am, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
> > On Mon, 31 Dec 2007 16:19:11 -0800, Scott David Daniels wrote:
>
> >> Steven D'Aprano wrote:
> >>> On Mon, 31 Dec 2007 08:03:22 -0800, Scott David Daniels wrote:
> Steven D'Aprano wrote: ...
> >
On Jan 2, iu2 <[EMAIL PROTECTED]> wrote:
> I missed new style classes though... Now I know how to use them (not
> fully), but I must say it has been difficult. I'll appreciate some
> good documentation about them.
>
> Thanks
> iu2
This is a decent start:
http://www.python.org/doc/newstyle/
Cheers
On Jan 1, 8:12 pm, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> We accept this seems natural to you. You don't seem to understand why
> others might not think so. I fear this is the kind of thing that
> separates programmers into two classes: the smart ones that can set up
> the chains, and
iu2 wrote:
> On Jan 1, 12:32 pm, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>> import read_my_mind_and_do_what_I_want
>> first. (Module expected in Python 9.7, due out in 2058.)
>
> That's because it seems to you like some esoteric feature.
> To me it seems natural with OO.
An
On Jan 1, 12:32 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
>
> import read_my_mind_and_do_what_I_want
>
> first. (Module expected in Python 9.7, due out in 2058.)
That's because it seems to you like some esoteric feature.
To me it seems natural with OO.
> "Special cases ar
On Mon, 31 Dec 2007 22:56:41 -0800, iu2 wrote:
> Indeed I might want to chain methods in all sort of ways:
> @chain_call_before - call the parent's method before the derived method
> @chain_call_after - call the parent's method after the derived method
> @chain_call_sum - sum the result of the par
On Jan 1, 9:59 am, Michele Simionato <[EMAIL PROTECTED]>
wrote:
> No PEP, this would never pass. There would be no way
> to stop a method from calling its parent: you would
> lose control of your classes, so I think this is a
> bad idea.
Not all classes, only classes the programmer chooses to hav
On Jan 1, 7:56 am, iu2 <[EMAIL PROTECTED]> wrote:
> no one has to remember to call the parent's get_name method. It's done
> automatically.
>
> (A PEP maybe? I sense you don't really like it.. ;-)
> What do you think? Good? Too implicit?
>
> iu2
No PEP, this would never pass. There would be no way
On Dec 31 2007, 6:03 pm, Scott David Daniels <[EMAIL PROTECTED]>
wrote:
> As to the original idea, better to give it up.
> Typically code for a "chained" method "foo" that
> returns a result will want to (in some way) use
> the result from that call in forming its result.
> Python's super allows yo
Steven D'Aprano wrote:
> On Mon, 31 Dec 2007 16:19:11 -0800, Scott David Daniels wrote:
>
>> Steven D'Aprano wrote:
>>> On Mon, 31 Dec 2007 08:03:22 -0800, Scott David Daniels wrote:
Steven D'Aprano wrote: ...
> def chain(meth): # A decorator for calling super.
> def f(self, *arg
On Mon, 31 Dec 2007 16:19:11 -0800, Scott David Daniels wrote:
> Steven D'Aprano wrote:
>> On Mon, 31 Dec 2007 08:03:22 -0800, Scott David Daniels wrote:
>>> Steven D'Aprano wrote: ...
def chain(meth): # A decorator for calling super.
def f(self, *args, **kwargs):
resul
Steven D'Aprano wrote:
> On Mon, 31 Dec 2007 08:03:22 -0800, Scott David Daniels wrote:
>> Steven D'Aprano wrote: ...
>>> def chain(meth): # A decorator for calling super.
>>> def f(self, *args, **kwargs):
>>> result = meth(self, *args, **kwargs)
>>> S = super(self.__class__, s
On Mon, 31 Dec 2007 08:03:22 -0800, Scott David Daniels wrote:
> Steven D'Aprano wrote:
>> ...
>> I'm not sure if this is your only problem or not, but super() only
>> works with new-style classes, not with classic classes. You must
>> inherit from object, or it cannot possibly work.
>>
>> Change
En Mon, 31 Dec 2007 12:08:43 -0200, Steven D'Aprano
<[EMAIL PROTECTED]> escribi�:
> On Mon, 31 Dec 2007 05:47:31 -0800, iu2 wrote:
>
>> I'm trying to make a method call automatically to its super using this
>> syntax:
>
>
> def chain(meth): # A decorator for calling super.
> def f(self, *ar
Steven D'Aprano wrote:
> ...
> I'm not sure if this is your only problem or not, but super() only works
> with new-style classes, not with classic classes. You must inherit from
> object, or it cannot possibly work.
>
> Change "class A" to "class A(object)".
Absolutely correct.
However, the sug
On Mon, 31 Dec 2007 05:47:31 -0800, iu2 wrote:
> Hi
>
> I'm trying to make a method call automatically to its super using this
> syntax:
[snip code]
I'm not sure if this is your only problem or not, but super() only works
with new-style classes, not with classic classes. You must inherit from
On 8/16/07, 7stud <[EMAIL PROTECTED]> wrote:
> When I run the following code and call super() in the Base class's
> __init__ () method, only one Parent's __init__() method is called.
As the other posters have mentioned, each class needs to make a call
to super. This is because the super call does
7stud wrote:
> When I run the following code and call super() in the Base class's
> __init__ () method, only one Parent's __init__() method is called.
>
>
> class Parent1(object):
> def __init__(self):
> print "Parent1 init called."
> self.x = 10
>
> class Parent2(object):
>
7stud <[EMAIL PROTECTED]> wrote:
> When I run the following code and call super() in the Base class's
> __init__ () method, only one Parent's __init__() method is called.
>
>
> class Parent1(object):
> def __init__(self):
> print "Parent1 init called."
> self.x = 10
>
> cla
Michele Simionato ha scritto:
> I believe the new style system was designed to allows this sort of
> mixing and
> that there are no issues at all.
Thinking a bit more, there are no issues at all if you know what a new
style class is and if you do not expect it to work as an old-style one
;) For th
Carl Banks ha scritto:
> Pupeno wrote:
> > I see, thank you.
> >
> > class MyConfig(ConfigParser, object):
> > def add_section(self, section)
> > super(MyConfig, self).add_section(section)
> >
> > seems to work and as expected. Is there anything wrong with it ?
>
> Wow.
>
> I highly r
Pupeno <[EMAIL PROTECTED]> wrote:
> class MyConfig(ConfigParser, object):
> def add_section(self, section)
> super(MyConfig, self).add_section(section)
>
> seems to work and as expected. Is there anything wrong with it ?
yes.
(1) There's a colon missing in the def-line. ;-)
(2) Th
Pupeno wrote:
> I see, thank you.
>
> class MyConfig(ConfigParser, object):
> def add_section(self, section)
> super(MyConfig, self).add_section(section)
>
> seems to work and as expected. Is there anything wrong with it ?
Wow.
I highly recommend not doing this, unless the new type
> I see, thank you.
>
> class MyConfig(ConfigParser, object):
> def add_section(self, section)
> super(MyConfig, self).add_section(section)
>
> seems to work and as expected. Is there anything wrong with it ?
>
I have never seen this before. :) I don't know the answer, but I'm
int
Laszlo Nagy wrote:
> Pupeno írta:
>> Hello,
>> I have a class called MyConfig, it is based on Python's
>> ConfigParser.ConfigParser.
>> It implements add_section(self, section), which is also implemented on
>> ConfigParser.ConfigParser, which I want to call.
>> So, reducing the problem to the bare
Pupeno írta:
> Hello,
> I have a class called MyConfig, it is based on Python's
> ConfigParser.ConfigParser.
> It implements add_section(self, section), which is also implemented on
> ConfigParser.ConfigParser, which I want to call.
> So, reducing the problem to the bare minimum, the class (with a
31 matches
Mail list logo
