On Jul 31, 5:08 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
I have read Michelle Simionato's articles on super in Python.
One l please! I am a man! ;-)
But Michelle is wrong to conclude that the problem lies with the concept
of *superclass*. The problem lies with the
Michele Simionato michele.simion...@gmail.com writes:
I am actually more radical than that. From
http://www.artima.com/weblogs/viewpost.jsp?thread=237121:
In this series I have argued that super is tricky; I think nobody can...
When I look at that URL, I see a Java stack dump:
Paul Rubin wrote:
Michele Simionato michele.simion...@gmail.com writes:
I am actually more radical than that. From
http://www.artima.com/weblogs/viewpost.jsp?thread=237121:
In this series I have argued that super is tricky; I think nobody can...
When I look at that URL, I see a Java
On Sun, 01 Aug 2010 23:15:11 -0700, Michele Simionato wrote:
On Jul 31, 5:08 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
I have read Michelle Simionato's articles on super in Python.
One l please! I am a man! ;-)
My apologies. You'd think I would know the difference
On 02/08/2010 10:23, Jean-Michel Pichavant wrote:
Paul Rubin wrote:
Michele Simionato michele.simion...@gmail.com writes:
I am actually more radical than that. From
http://www.artima.com/weblogs/viewpost.jsp?thread=237121:
In this series I have argued that super is tricky; I think nobody
On 02/08/2010 07:15, Michele Simionato wrote:
On Jul 31, 5:08 am, Steven D'Apranost...@remove-this-
cybersource.com.au wrote:
I have read Michelle Simionato's articles on super in Python.
One l please! I am a man! ;-)
Please prove it, get your bits out!!! :)
M. Simionato
Steven D'Aprano wrote:
On Sat, 31 Jul 2010 13:29:25 +, Brian Victor wrote:
Steven D'Aprano wrote:
On Sat, 31 Jul 2010 14:25:39 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
A
/ \
C B
\ /
D
/ \
E F
Yes, a super call might jog left from C to
On 02/08/2010 17:35, Mark Lawrence wrote:
aka the colon. :)
Ha. This is a case of the colon being the appendix!
\d
--
http://mail.python.org/mailman/listinfo/python-list
On 02/08/2010 17:53, donn wrote:
On 02/08/2010 17:35, Mark Lawrence wrote:
aka the colon. :)
Ha. This is a case of the colon being the appendix!
\d
Is there a better newsgroup in the world than c.l.py? No!
Kindest regards.
Mark Lawrence.
--
On Sat, 31 Jul 2010 13:29:25 +, Brian Victor wrote:
Steven D'Aprano wrote:
On Sat, 31 Jul 2010 14:25:39 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
A
/ \
C B
\ /
D
/ \
E F
Yes, a super call might jog left from C to B, but only when
Steven D'Aprano wrote:
super(C, self)
shouldn't be interpreted as call C's superclasses from self. It means
starting just after C in the MRO, call self.__class__'s superclasses.
My contention is that nobody has any chance of guessing what
it does based on the name super. Superness doesn't
On Fri, 30 Jul 2010 21:40:21 -0600, Ian Kelly wrote:
I have to chime in and agree that the name super is problematic. I'm
reading this thread with a sense of alarm because I apparently never
read the super() documentation too closely (why would I? Oh, it just
accesses an attribute from a
Steven D'Aprano wrote:
On Sat, 31 Jul 2010 14:25:39 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
A
/ \
C B
\ /
D
/ \
E F
Yes, a super call might jog left from C to B, but only when being
called from one of the lower classes D-F. That's
On Sat, Jul 31, 2010 at 4:22 AM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
On Fri, 30 Jul 2010 21:40:21 -0600, Ian Kelly wrote:
I have to chime in and agree that the name super is problematic. I'm
reading this thread with a sense of alarm because I apparently never
read the
Steven D'Aprano wrote:
Assuming you accurately tell it the current class, can you give an
example where super() doesn't refer to a superclass of the current class?
I think we're all confusing each other in this discussion
by not being clear enough about what we mean by the current
class.
In
Ian Kelly wrote:
super(type[, object-or-type])
...
The __mro__ attribute of the type lists the method resolution
search order used by both getattr() and super(). The attribute is
dynamic and can change whenever the inheritance hierarchy is updated.
That explanation does seem to be
On Jul 31, 11:16 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sat, Jul 31, 2010 at 4:22 AM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
On Fri, 30 Jul 2010 21:40:21 -0600, Ian Kelly wrote:
I have to chime in and agree that the name super is problematic. I'm
reading
On Jul 31, 8:48 pm, Carl Banks pavlovevide...@gmail.com wrote:
When you have a class you that don't anything about the implementation
of, that is NOT the place for inheritance.
And, just to be clear, if the class is explicity documented as being
subclassable and the documentation states the
Steven D'Aprano wrote:
super() is just as explicit as len(), or str.upper(). It says,
explicitly, that it will call the method belonging to one or more
superclass of the given class.
That's not strictly true. It will call a method belonging to some
class in the mro of self, but that class is
Steven D'Aprano wrote:
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
mro would have been the proper name for super.
That's your opinion. In any case, whether super() was called super() or
mro() or aardvark() makes no difference to the functionality or whether
it is
Steven D'Aprano wrote:
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
[snip]
As someone already said in this list, the main problem with super is
that it tends to refer to the superclass method while in fact it calls
the next MRO method.
Why do you think that is a
On Fri, 30 Jul 2010 19:35:52 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
super() is just as explicit as len(), or str.upper(). It says,
explicitly, that it will call the method belonging to one or more
superclass of the given class.
That's not strictly true. It will call a method
On Fri, 30 Jul 2010 19:37:29 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
mro would have been the proper name for super.
That's your opinion. In any case, whether super() was called super() or
mro() or aardvark()
Steven D'Aprano wrote:
On Fri, 30 Jul 2010 19:37:29 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
mro would have been the proper name for super.
That's your opinion. In any case, whether
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
I think the point is that the name is misleading, because it makes it
*sound* like it's going to call a method in a superclass, when it fact
it might not.
That is indeed confusing to some people, especially those who refuse to
to accept the
On Jul 25, 5:30 pm, Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
Raymond Hettinger wrote:
Every class
in the MRO implementing the target method *must* call super() to give
the next class in the MRO a chance to run.
EXCEPT for the last one, which must NOT call super!
The posted
Steven D'Aprano wrote:
A
/ \
C B
\ /
D
/ \
E F
Yes, a super call might jog left from
C to B, but only when being called from one of the lower classes D-F.
That's still an upwards call relative to the originator, not sidewards.
But it's not an upward
On Sat, 31 Jul 2010 14:25:39 +1200, Gregory Ewing wrote:
Steven D'Aprano wrote:
A
/ \
C B
\ /
D
/ \
E F
Yes, a super call might jog left from C to B, but only when being
called from one of the lower classes D-F. That's still an upwards call
On Fri, 30 Jul 2010 14:43:07 +0200, Jean-Michel Pichavant wrote:
Quoting Michele's article (I think he's still hanging around this list)
Readers familiar will single inheritance languages, such as Java or
Smalltalk, will have a clear concept of superclass in mind. This
concept, however, has
On Fri, Jul 30, 2010 at 6:38 AM, Hrvoje Niksic hnik...@xemacs.org wrote:
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
I think the point is that the name is misleading, because it makes it
*sound* like it's going to call a method in a superclass, when it fact
it might not.
That is
Steven D'Aprano wrote:
On Sun, 25 Jul 2010 13:58:00 +1200, Gregory Ewing wrote:
Lacrima wrote:
But what if SuperClass1 is from third party library?
If it hasn't been designed for super(), then you can't use super() with
it.
super() only works when *every* class in the
On Thu, 29 Jul 2010 12:08:54 +0200, Jean-Michel Pichavant wrote:
Steven D'Aprano wrote:
That incorrect. You can certainly use super() with classic classes in
the hierarchy, and super() didn't even exist when they were created.
The problem isn't super(), and people who give glib advise don't
Steven D'Aprano wrote:
[snip]
super() is just as explicit as len(), or str.upper(). It says,
explicitly, that it will call the method belonging to one or more
superclass of the given class.
Come on Steven, you're better than this :) .
Everybody can accurately guess what len and upper are
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
Steven D'Aprano wrote:
[snip]
super() is just as explicit as len(), or str.upper(). It says,
explicitly, that it will call the method belonging to one or more
superclass of the given class.
Come on Steven, you're better
Gregory Ewing wrote:
Raymond Hettinger wrote:
Every class
in the MRO implementing the target method *must* call super() to give
the next class in the MRO a chance to run.
EXCEPT for the last one, which must NOT call super!
The posted example happens to work because object has
a default
[Ethan Furman]
Speaking of new-style classes only, don't they all end in object? And
if the MRO is only known at run-time, how is one to know at code-time
whether your (new-style) class is at the end of the line?
That is a bit of a PITA. One way of handling it is to design your
diamond so
On Jul 24, 3:56 am, Lacrima lacrima.ma...@gmail.com wrote:
Thank you for your answer.
You're welcome.
Some things are still not clear. Your example works great. But if I
remove super(SuperClass1, self).__init__(**kwds) from SuperClass1's
__init__, the example stops working. That is when I
Raymond Hettinger wrote:
Every class
in the MRO implementing the target method *must* call super() to give
the next class in the MRO a chance to run.
EXCEPT for the last one, which must NOT call super!
The posted example happens to work because object has
a default __init__ method that does
Everything you ever wanted to know about super is collected here:
http://micheles.googlecode.com/hg/artima/python/super.pdf
M.S.
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 24, 12:47 am, Lacrima lacrima.ma...@gmail.com wrote:
Hi!
I have two super classes:
class SuperClass1(object):
def __init__(self, word):
print word
class SuperClass2(object):
def __init__(self, word, word2):
print word, word2
Also I have subclass of these
On Jul 24, 11:20 am, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Jul 24, 12:47 am, Lacrima lacrima.ma...@gmail.com wrote:
Hi!
I have two super classes:
class SuperClass1(object):
def __init__(self, word):
print word
class SuperClass2(object):
def
Lacrima wrote:
But what if SuperClass1 is from third party library?
If it hasn't been designed for super(), then you
can't use super() with it.
super() only works when *every* class in the
hierarchy has been designed with it in mind.
--
Greg
--
On Sun, 25 Jul 2010 13:58:00 +1200, Gregory Ewing wrote:
Lacrima wrote:
But what if SuperClass1 is from third party library?
If it hasn't been designed for super(), then you can't use super() with
it.
super() only works when *every* class in the hierarchy has been designed
with it in
43 matches
Mail list logo
