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 it
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
> indepen
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 take
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 was
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 inhe
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 strikin
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 n
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
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.
Conversely
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
-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
(plus,
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
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
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
mu
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
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",
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
Hi,
Guido van Rossum 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 of prac
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 t
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 became
20 matches
Mail list logo
