On Fri, 2 May 2008, Greg Ewing wrote:
Guido van Rossum wrote:
The
alternative would be to make it a keyword, which seemed excessive
(plus, it would be odd if super() were a keyword when self is not).
If it's really such a useful thing as to warrant so much
magic to support it, then I think
On May 2, 7:54 am, Greg Ewing [EMAIL PROTECTED] wrote:
I can only speak from my own experience, which is that
whenever I've had a problem involving multiple inheritance,
super() didn't solve it. What did solve it was either
refactoring so that the classes being mixed were more
independent,
Jared Flatow wrote:
I agree that if your methods are 'clashing' then you are
probably misinheriting, but cooperative methods can be the most natural
way to model certain situations.
I'm not saying that nobody should ever use super, only
that it's not the right thing for the situation I
Barry Warsaw wrote:
I think of all the alternatives in PEP 3135, I'd probably prefer
self.__super__.foo(), except that I'd call it self.super.foo().
I'm not sure that's sufficient. You need to be able to specify a class
when using MI.
I'd prefer self.super().foo(). self.super() would
Hi,
Guido van Rossum guido at python.org writes:
The staticmethod thing isn't new; that's also the case in 2.x.
staticmethod hasn't changed, method has. In the past Class.method gave
you a unbound method, now you get a function back as if it was a static
method.
The super() thing is a case
Armin Ronacher schrieb:
The super() thing is a case of practicality beats purity. Note that
you pay a small but measurable cost for the implicit __class__ (it's
implemented as a cell variable, the same mechanism used for nested
scopes) so we wouldn't want to introduce it unless it is used.
I
2008/5/1, Georg Brandl [EMAIL PROTECTED]:
There may be more implications and surprising behavior surrounding this.
I know that the implementation is a compromise, but I'd rather see a
super()
whose full semantics can be explained to programmers without using to
cell variable,
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl [EMAIL PROTECTED] wrote:
But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really strikingly unpythonic in
my
At 04:38 PM 5/1/2008 -0300, Facundo Batista wrote:
Has super() proved more useful than harmful?
For me, yes. I use it all the time. The only time I use
explicit-target upcalls is in __init__ methods, and there usually
only to skip a subclass' init or to explicitly manage a tricky bit of
2008/5/1 Facundo Batista [EMAIL PROTECTED]:
2008/5/1, Georg Brandl [EMAIL PROTECTED]:
There may be more implications and surprising behavior surrounding
this.
I know that the implementation is a compromise, but I'd rather see a
super()
whose full semantics can be explained to
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:
I'm not proud of this, but I don't see a way around it. The
alternative would be to make it a keyword, which seemed excessive
(plus, it would be odd if super() were a keyword when self is not).
There were long discussions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 6:33 PM, Andrew McNabb wrote:
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:
I'm not proud of this, but I don't see a way around it. The
alternative would be to make it a keyword, which seemed excessive
Facundo Batista wrote:
Has super() proved more useful than harmful? Which is the value for
Py3 to keep it?
Personally I've found exactly zero use cases for super()
so far in my own code. A couple of times I thought I'd
found one, but it turned out not to do quite what I
wanted, and I ended up
Guido van Rossum wrote:
The
alternative would be to make it a keyword, which seemed excessive
(plus, it would be odd if super() were a keyword when self is not).
If it's really such a useful thing as to warrant so much
magic to support it, then I think it deserves to have a
keyword.
Phillip J. Eby wrote:
(Note, by the way, that you cannot safely write an upcall in a mixin
class without super, so it can't safely be done away with, anyway.)
It seems to me you can't safely write one in a mixin class
*with* super either. I know that's what it's supposed to be
for, but I can't
Gustavo Carneiro wrote:
A better question would be, is multiple inheritance good or bad for
programs? :-)
I would say there are good ways of using it, and bad
ways of using it.
In my experience, the good ways occur when the classes
being mixed together are completely independent -- there
is
Guido van Rossum schrieb:
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl [EMAIL PROTECTED] wrote:
But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really
On May 1, 2008, at 9:21 PM, Greg Ewing wrote:
If the classes being mixed clash or overlap in functionality
somehow, the inheriting class needs to override all of the
clashing methods and properties and resolve matters by
delegating to one or another of the inherited classes
(using explicit
Hi all,
I blogged about that topic today which turned out to be a very bad idea,
so I summarize it for the mailinglist here to hopefully start a discussion
about the topic, which I think is rather important.
In the last weeks something remarkable happened in the Python3 sources:
self kinda
The staticmethod thing isn't new; that's also the case in 2.x.
The super() thing is a case of practicality beats purity. Note that
you pay a small but measurable cost for the implicit __class__ (it's
implemented as a cell variable, the same mechanism used for nested
scopes) so we wouldn't want to
20 matches
Mail list logo
