On Jan 6, 2005, at 12:13 PM, Guido van Rossum wrote:
So it has nothing to do with the new paradigm, just with backwards
compatibility. I appreciate those issues (more than you'll ever know)
but I don't see why you should try to discourage others from using the
new paradigm, which is what your artic
On Jan 6, 2005, at 5:45 PM, Delaney, Timothy C (Timothy) wrote:
Well, there's my autosuper recipe you've seen before:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195
which does basically what Philip descibes ...
You missed the most important part of the example -- the automatic
argu
Guido van Rossum wrote:
>> and the cumbersome way in which you have to invoke super.
>
> Given Python's dynamic nature I couldn't think of a way to make it
> less cumbersome. I see you tried (see below) and couldn't either. At
> this point I tend to say "put up or shut up."
Well, there's my auto
On 2005 Jan 06, at 20:16, Terry Reedy wrote:
"James Y Knight" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Please notice that I'm talking about concrete, real issues, not just a
"super is bad!" rant.
Umm, James, come on. Let's be really real and concrete ;-).
Your title "Python's Su
[Guido]
>> Then why is the title "Python's Super Considered Harmful" ???
>>
>> Here's my final offer. Change the title to something like "Multiple
>> Inheritance Pitfalls in Python" and nobody will get hurt.
[Bill Janssen]
> Or better yet, considering the recent thread on Python marketing,
> "Mul
> Then why is the title "Python's Super Considered Harmful" ???
>
> Here's my final offer. Change the title to something like "Multiple
> Inheritance Pitfalls in Python" and nobody will get hurt.
Or better yet, considering the recent thread on Python marketing,
"Multiple Inheritance Mastery in P
"James Y Knight" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Please notice that I'm talking about concrete, real issues, not just a
> "super is bad!" rant.
Umm, James, come on. Let's be really real and concrete ;-).
Your title "Python's Super Considered Harmful" is an obviou
At 02:46 AM 1/6/05 -0500, James Y Knight wrote:
To fix #1, it would be really nice if you could write code something like
the following snippet. Notice especially here that the 'bar' argument gets
passed through C.__init__ and A.__init__, into D.__init__, without the
previous two having to do an
> Please notice that I'm talking about concrete, real issues, not just a
> "super is bad!" rant.
Then why is the title "Python's Super Considered Harmful" ???
Here's my final offer. Change the title to something like "Multiple
Inheritance Pitfalls in Python" and nobody will get hurt.
> They are
On Jan 5, 2005, at 6:36 PM, Guido van Rossum wrote:
The idea of calling both __init__ methods doesn't work if there's a
diamond; if there *is* a diamond (or could be one), using super() is
the only sane solution.
Very true.
So then don't use it. You couldn't have diamonds at all before 2.2.
With *c
On Wed, 5 Jan 2005 18:00:38 -0500, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2005, at 1:23 PM, Guido van Rossum wrote:
> >> The issue of mixing super() and explicit calls to the superclass's
> >> method occur with any method. (Thus making it difficult/impossible for
> >> a framework to
On Jan 5, 2005, at 1:23 PM, Guido van Rossum wrote:
The issue of mixing super() and explicit calls to the superclass's
method occur with any method. (Thus making it difficult/impossible for
a framework to convert to using super without breaking client code
that
subclasses).
Well, client classes wh
> The issue of mixing super() and explicit calls to the superclass's
> method occur with any method. (Thus making it difficult/impossible for
> a framework to convert to using super without breaking client code that
> subclasses).
Well, client classes which are leaves of the class tree can still
s
I'm not sure why super got dragged into this, but...
On Jan 4, 2005, at 9:02 PM, Guido van Rossum wrote:
I think that James Y Knight's page misrepresents the issue. Quoting:
But __init__ *is* special, in that it is okay for a subclass __init__
(or __new__) to have a different signature than the ba
14 matches
Mail list logo
