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
35 matches
Mail list logo
