I'm on the fence about dropping __var (some people back in the days
*begged* for it, and it had nothing to do with super; I wonder what
they think now).
But I'm all for adding syntactic sugar to Py3k. Can someone please
draft a proto-PEP? I think the compiler could treat super as a
reserved word a
Guido van Rossum wrote:
> But I'm all for adding syntactic sugar to Py3k. Can someone please
> draft a proto-PEP? I think the compiler could treat super as a
> reserved word and turn super.foo(args) into __super__(,
> self).foo(args). Or something. Please be sure you understand the
> issues (e.g.
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm on the fence about dropping __var (some people back in the days
> *begged* for it, and it had nothing to do with super; I wonder what
> they think now).
Until Christian Tanzer's post, the only good use case I had seen was
extreme backwa
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But I'm all for adding syntactic sugar to Py3k. Can someone please
> draft a proto-PEP? I think the compiler could treat super as a
> reserved word and turn super.foo(args) into __super__(,
> self).foo(args).
Are you saying that it would be
On Sunday 01 October 2006 17:20, Giovanni Bajo wrote:
> Would you want this PEP to address the fact that, in most cases, you just
> want to forward all the arguments to super call (aka super.foo(*args,
> **args)), ala Dylan's nextmethod? Or is this what you meant with KISS? :)
It's not at all c
Guido van Rossum wrote:
> I think the compiler could treat super as a
> reserved word and turn super.foo(args) into __super__(,
> self).foo(args). Or something.
That sounds reasonable.
What would you do in the case of multiple base classes?
--
Greg
___
Giovanni Bajo wrote:
> Would you want this PEP to address the fact that, in most cases, you just want
> to forward all the arguments to super call (aka super.foo(*args, **args))
I dispute this. By far the majority of the super calls
that I make are to __init__ methods, and I almost
always do *not
