Ethan Furman wrote:
> foo(x=1, y=2, z=3)
>> Traceback (most recent call last):
>> File "", line 1, in
>> foo(x=1, y=2, z=3)
>> File "", line 2, in foo
>> bar(y=2, **kwargs)
>> TypeError: bar() got multiple values for keyword argument 'y'
>
> And the above error is exactly why yo
Am 28.05.2011 01:57 schrieb sturlamolden:
Yes. And opposite: CPython cannot know that builtin super() is not
called,
even if it does not see the name 'super'. I can easily make foo()
alias super().
Another alternative would have been to make use of __xxx magic.
If every class had an "automati
On 27 Mai, 18:06, Steven D'Aprano wrote:
> Why? The fault is not that super is a function, or that you monkey-
> patched it, or that you used a private function to do that monkey-
> patching. The fault was that you made a common, but silly, mistake when
> reasoning about type(self) inside a class
On 27 Mai, 23:49, Stefan Behnel wrote:
> I think Sturla is referring to the "compile time" bit. CPython cannot know
> that the builtin super() will be called at runtime, even if it sees a
> "super()" function call.
Yes. And opposite: CPython cannot know that builtin super() is not
called,
even i
On Fri, 2011-05-27 at 15:05 +, Duncan Booth wrote:
> sturlamolden wrote:
> > I really don't like the Python 2 syntax of super, as it violates
> > the DRY principle: Why do I need to write super(type(self),self)
> > when super() will do? Assuming that 'self' will always be named
> > 'self' in m
I suspect the larger issue is that Multiple Inheritance is complex, but
folks don't appreciate that. Ask anyone about meta-classes and their
eyes bug-out, but MI? Simple! NOT.
On the other hand, perhaps the docs should declare that the built-in
objects are not designed for MI, so that that,
Steven D'Aprano, 27.05.2011 18:06:
On Fri, 27 May 2011 08:31:40 -0700, sturlamolden wrote:
On 27 Mai, 17:05, Duncan Booth wrote:
Oops. There's a reason why Python 2 requires you to be explicit about
the class; you simply cannot work it out automatically at run time.
Python 3 fixes this by wo
On 5/27/2011 11:46 AM, Chris Angelico wrote:
On Sat, May 28, 2011 at 4:31 AM, Ian Kelly wrote:
It seems to me that the example of combining built-in dictionary
classes is naively optimistic.
So... Can anyone offer a non-trivial example of multiple inheritance
that *doesn't* have pitfalls? F
On Sat, May 28, 2011 at 4:31 AM, Ian Kelly wrote:
> It seems to me that the example of combining built-in dictionary
> classes is naively optimistic.
So... Can anyone offer a non-trivial example of multiple inheritance
that *doesn't* have pitfalls? From what I've seen, MI always seems to
require
On Sat, May 28, 2011 at 4:10 AM, Prasad, Ramit
wrote:
>>>We also, though, need *real* URLs. Blind URLs through obfuscation
>>>services have their uses, but surely not in a forum like this. The real
>>>URL is http://news.ycombinator.com/item?id=2588262>.
>
> I remember reading a news article where
On Thu, May 26, 2011 at 10:31 AM, Raymond Hettinger wrote:
> I just posted a tutorial and how-to guide for making effective use of
> super().
I posted this already on the HackerNews thread but it seems to have
largely gone unnoticed, so I'm reposting it here.
It seems to me that the example of c
>>We also, though, need *real* URLs. Blind URLs through obfuscation
>>services have their uses, but surely not in a forum like this. The real
>>URL is http://news.ycombinator.com/item?id=2588262>.
I remember reading a news article where a man was arrested (or was it fired)
for pornography because
On Fri, May 27, 2011 at 4:37 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> On Fri, 27 May 2011 18:49:52 +1000, Ben Finney wrote:
>
> > Raymond Hettinger writes:
> >
> >> Hope you enjoyed the post.
> >
> > I certainly did.
> >
> > But I'm not better enlightened on why ‘super
Duncan Booth wrote:
Steven D'Aprano wrote:
I was thrilled to learn a new trick, popping keyword arguments before
calling super, and wondered why I hadn't thought of that myself. How on
earth did I fail to realise that a kwarg dict was mutable and therefore
you can remove keyword args, or inj
On Fri, 27 May 2011 08:31:40 -0700, sturlamolden wrote:
> On 27 Mai, 17:05, Duncan Booth wrote:
>
>> Oops. There's a reason why Python 2 requires you to be explicit about
>> the class; you simply cannot work it out automatically at run time.
>> Python 3 fixes this by working it out at compile ti
On 27 Mai, 17:05, Duncan Booth wrote:
> Oops. There's a reason why Python 2 requires you to be explicit about
> the class; you simply cannot work it out automatically at run time.
> Python 3 fixes this by working it out at compile time, but for Python 2
> there is no way around it.
Then it shoul
On 27 Mai, 17:05, Duncan Booth wrote:
> >>> class C(B): pass
> >>> C().foo()
>
> ... infinite recursion follows ...
That's true :(
--
http://mail.python.org/mailman/listinfo/python-list
On 27 Mai, 16:27, sturlamolden wrote:
> Assuming that 'self' will always be named
> 'self' in my code, I tend to patch __builtins__.super like this:
>
> import sys
> def super():
> self = sys._getframe().f_back.f_locals['self']
> return __builtins__.super(type(self),self)
A monkey-patch
Steven D'Aprano wrote:
Python causes trouble by letting the users get at the internals, but
> things like this make it worthwhile.
Only if by "worthwhile" you mean "buggy as hell".
I *don't* believe this... the king of metaphors and bogus analogies
has come up with 'buggy as hell' !!?
sturlamolden wrote:
> On 26 Mai, 18:31, Raymond Hettinger wrote:
>> I just posted a tutorial and how-to guide for making effective use of
>> super().
>>
>> One of the reviewers, David Beazley, said, "Wow, that's really
>> great! I see this becoming the definitive post on the subject"
>>
>> T
The fact that even experienced programmers fail to see that
super(type(self),self) in Python 2 is NOT equivalent to super()
in Python 3 is telling something.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 27 May 2011 10:33:20 -0400, Mel wrote:
> sturlamolden wrote:
>
>> I really don't like the Python 2 syntax of super, as it violates the
>> DRY principle: Why do I need to write super(type(self),self) when
>> super() will do? Assuming that 'self' will always be named 'self' in my
>> code, I
sturlamolden wrote:
> I really don't like the Python 2 syntax of super, as it violates
> the DRY principle: Why do I need to write super(type(self),self)
> when super() will do? Assuming that 'self' will always be named
> 'self' in my code, I tend to patch __builtins__.super like this:
>
> import
On 26 Mai, 18:31, Raymond Hettinger wrote:
> I just posted a tutorial and how-to guide for making effective use of
> super().
>
> One of the reviewers, David Beazley, said, "Wow, that's really
> great! I see this becoming the definitive post on the subject"
>
> The direct link is:
>
> http://
Steven D'Aprano wrote:
> I was thrilled to learn a new trick, popping keyword arguments before
> calling super, and wondered why I hadn't thought of that myself. How on
> earth did I fail to realise that a kwarg dict was mutable and therefore
> you can remove keyword args, or inject new ones i
On Fri, 27 May 2011 18:49:52 +1000, Ben Finney wrote:
> Raymond Hettinger writes:
>
>> Hope you enjoyed the post.
>
> I certainly did.
>
> But I'm not better enlightened on why ‘super’ is a good thing.
Perhaps Raymond assumed that by now everybody knows that multiple
inheritance in Python t
On Friday, May 27, 2011 10:49:52 AM UTC+2, Ben Finney wrote:
> The exquisite care that you describe programmers needing to maintain is IMO
> just as much a deterrent as the super-is-harmful essay.
Worth quoting. Also I think this article may encourage naive programmers along
the dark path of coop
Raymond Hettinger writes:
> Hope you enjoyed the post.
I certainly did.
But I'm not better enlightened on why ‘super’ is a good thing. The
exquisite care that you describe programmers needing to maintain is IMO
just as much a deterrent as the super-is-harmful essay.
--
\“If you c
On May 26, 6:39 pm, Ben Finney wrote:
> We also, though, need *real* URLs. Blind URLs through obfuscation
> services have their uses, but surely not in a forum like this. The real
> URL is http://news.ycombinator.com/item?id=2588262>.
Fair enough. I had copied the link from Jesse's tweet (where
Raymond Hettinger writes:
> I just posted a tutorial and how-to guide for making effective use of
> super().
Thanks very much! We need articles like this.
Raymond Hettinger writes:
> Here's a link to the super() how-to-guide and commentary: bit.ly/
> iFm8g3
We also, though, need *real* URLs
On 5/26/2011 2:13 PM, Dotan Cohen wrote:
On Thu, May 26, 2011 at 19:39, Raymond Hettinger wrote:
It would also be great if some of you would upvote it on HackerNews.
Here's a link to the super() how-to-guide and commentary: bit.ly/
iFm8g3
Is that the same link as in the OP? I don't click
On Thu, May 26, 2011 at 21:38, Ian Kelly wrote:
> It's a link to ycombinator:
>
> http://news.ycombinator.com/item?id=2588262
>
Thanks.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, May 26, 2011 at 12:13 PM, Dotan Cohen wrote:
> On Thu, May 26, 2011 at 19:39, Raymond Hettinger wrote:
>>> It would also be great if some of you would upvote it on HackerNews.
>>
>>
>> Here's a link to the super() how-to-guide and commentary: bit.ly/
>> iFm8g3
>>
>
> Is that the same lin
On Thu, May 26, 2011 at 19:39, Raymond Hettinger wrote:
>> It would also be great if some of you would upvote it on HackerNews.
>
>
> Here's a link to the super() how-to-guide and commentary: bit.ly/
> iFm8g3
>
Is that the same link as in the OP? I don't click on blind links, so
if it isn't then
> It would also be great if some of you would upvote it on HackerNews.
Here's a link to the super() how-to-guide and commentary: bit.ly/
iFm8g3
Raymod
--
http://mail.python.org/mailman/listinfo/python-list
I just posted a tutorial and how-to guide for making effective use of
super().
One of the reviewers, David Beazley, said, "Wow, that's really
great!I see this becoming the definitive post on the subject"
The direct link is:
http://rhettinger.wordpress.com/2011/05/26/super-considered-super
36 matches
Mail list logo
