Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6328 > unrolled thread

Python's super() considered super!

Back to article view | Back to comp.lang.python

Contents

  Python's super() considered super! Raymond Hettinger <python@rcn.com> - 2011-05-26 09:31 -0700
    Re: Python's super() considered super! Raymond Hettinger <python@rcn.com> - 2011-05-26 09:39 -0700
      Re: Python's super() considered super! Dotan Cohen <dotancohen@gmail.com> - 2011-05-26 21:13 +0300
      Re: Python's super() considered super! Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-26 12:38 -0600
      Re: Python's super() considered super! Dotan Cohen <dotancohen@gmail.com> - 2011-05-26 21:56 +0300
      Re: Python's super() considered super! Terry Reedy <tjreedy@udel.edu> - 2011-05-26 16:15 -0400
    Re: Python's super() considered super! Ben Finney <ben+python@benfinney.id.au> - 2011-05-27 11:39 +1000
      Re: Python's super() considered super! Raymond Hettinger <python@rcn.com> - 2011-05-27 00:16 -0700
        Re: Python's super() considered super! Ben Finney <ben+python@benfinney.id.au> - 2011-05-27 18:49 +1000
          Re: Python's super() considered super! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 10:37 +0000
            Re: Python's super() considered super! Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-27 10:53 +0000
              Re: Python's super() considered super! Ethan Furman <ethan@stoneleaf.us> - 2011-05-27 10:42 -0700
                Re: Python's super() considered super! Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-30 09:18 +0000
      RE: Python's super() considered super! "Prasad, Ramit" <ramit.prasad@jpmchase.com> - 2011-05-27 14:10 -0400
      Re: Python's super() considered super! Chris Angelico <rosuav@gmail.com> - 2011-05-28 04:40 +1000
    Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 07:27 -0700
      Re: Python's super() considered super! Mel <mwilson@the-wire.com> - 2011-05-27 10:33 -0400
        Re: Python's super() considered super! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 14:49 +0000
          Re: Python's super() considered super! harrismh777 <harrismh777@charter.net> - 2011-05-27 10:07 -0500
      Re: Python's super() considered super! Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-27 15:05 +0000
        Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 08:24 -0700
        Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 08:31 -0700
          Re: Python's super() considered super! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 16:06 +0000
            Re: Python's super() considered super! Stefan Behnel <stefan_ml@behnel.de> - 2011-05-27 23:49 +0200
              Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 16:57 -0700
                Re: Python's super() considered super! Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-05-28 07:29 +0200
            Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 17:04 -0700
        Re: Python's super() considered super! Ryan Kelly <ryan@rfk.id.au> - 2011-05-28 09:57 +1000
      Re: Python's super() considered super! sturlamolden <sturlamolden@yahoo.no> - 2011-05-27 08:11 -0700
    Re: Python's super() considered super! Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-27 12:31 -0600
    Re: Python's super() considered super! Chris Angelico <rosuav@gmail.com> - 2011-05-28 04:46 +1000
      Re: Python's super() considered super! John Nagle <nagle@animats.com> - 2011-05-27 13:47 -0700
    Re: Python's super() considered super! Ethan Furman <ethan@stoneleaf.us> - 2011-05-27 15:24 -0700

Page 1 of 2  [1] 2  Next page →

#6328 — Python's super() considered super!

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/

It would also be great if some of you would upvote it on HackerNews.


Raymond Hettinger
-----------------------
follow my python tips on twitter: @raymondh

[toc] | [next] | [standalone]

#6329

> 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

[toc] | [prev] | [next] | [standalone]

#6332

On Thu, May 26, 2011 at 19:39, Raymond Hettinger <python@rcn.com> 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 please post a direct link. Thanks.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[toc] | [prev] | [next] | [standalone]

#6334

On Thu, May 26, 2011 at 12:13 PM, Dotan Cohen <dotancohen@gmail.com> wrote:
> On Thu, May 26, 2011 at 19:39, Raymond Hettinger <python@rcn.com> 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 please post a direct link. Thanks.

It's a link to ycombinator:

http://news.ycombinator.com/item?id=2588262

[toc] | [prev] | [next] | [standalone]

#6337

On Thu, May 26, 2011 at 21:38, Ian Kelly <ian.g.kelly@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#6341

On 5/26/2011 2:13 PM, Dotan Cohen wrote:
> On Thu, May 26, 2011 at 19:39, Raymond Hettinger<python@rcn.com>  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 please post a direct link. Thanks.

It is a link to HackerNews
http://news.ycombinator.com/item?id=2588262

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#6358

Raymond Hettinger <python@rcn.com> 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 <python@rcn.com> writes:

> Here's a link to the super() how-to-guide and commentary:  bit.ly/
> iFm8g3

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 <URL:http://news.ycombinator.com/item?id=2588262>.

-- 
 \        “… it's best to confuse only one issue at a time.” —Brian W. |
  `\    Kernighan and Dennis M. Ritchie, _The C programming language_, |
_o__)                                                             1988 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#6376

On May 26, 6:39 pm, Ben Finney <ben+pyt...@benfinney.id.au> 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 <URL:http://news.ycombinator.com/item?id=2588262>.

Fair enough.  I had copied the link from Jesse's tweet (where shorter
is better).

Hope you enjoyed the post.


Raymond

[toc] | [prev] | [next] | [standalone]

#6378

Raymond Hettinger <python@rcn.com> 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 continue running Windows, your system may become |
  `\        unstable.” —Microsoft, Windows 95 bluescreen error message |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#6383

On Fri, 27 May 2011 18:49:52 +1000, Ben Finney wrote:

> Raymond Hettinger <python@rcn.com> 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 that doesn't use super is buggy. super() was 
introduced in version 2.2 in order to overcome bugs in MI, making it 
about 8 years old now.

(Technically, it's only MI with diamond-shaped inheritance, but that 
applies to *all* new-style classes. If you're writing multiple 
inheritance in Python 3 without using super, your code is a land-mine 
waiting to go off. If you're writing single inheritance, it's *still* a 
land-mine, just waiting for some poor caller to use it in a MI context.)

But I do agree with you in that I expected to see at least some 
discussion of why super should be actively preferred over calling the 
parent class directly.


> The
> exquisite care that you describe programmers needing to maintain is IMO
> just as much a deterrent as the super-is-harmful essay.

I don't see that Raymond describes anything needing "exquisite care". 
It's more common sense really: ensure that your method signature and that 
of your parents' match, plus good work-arounds for when they don't. 
Anyone using inheritance is almost certainly 98% of the way there, unless 
they're writing classes like this and wondering why they don't work :)

class MyBrokenList(list):
    def __len__(self):
        n = list.__len__(self, extra=42)
        return n + 1
    def __getitem__(self, i):
        return list.__getitem__(self) + 1
    def last_item(self):
        return list.last_item(self) + 1


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 in?

Given the plethora of articles that take a dim, if not outright negative, 
view of super, it is good to see one that takes a positive view. Thanks 
Raymond!



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#6384

Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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 in?
> 
Probably because most of the time it is better to avoid mutating kwargs. 
Instead of popping an argument you simply declare it as a named argument in 
the method signature. Instead of injecting new ones you can pass them as 
named arguments.


def foo(x=None, **kwargs):
	bar(y=2, **kwargs)

	
def bar(**kwargs):
	print(kwargs)

>>> foo(x=1, z=3)
{'y': 2, 'z': 3}
>>> foo(x=1, y=2, z=3)
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    foo(x=1, y=2, z=3)
  File "<pyshell#4>", line 2, in foo
    bar(y=2, **kwargs)
TypeError: bar() got multiple values for keyword argument 'y'

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#6414

Duncan Booth wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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 in?
>>
> Probably because most of the time it is better to avoid mutating kwargs. 
> Instead of popping an argument you simply declare it as a named argument in 
> the method signature. Instead of injecting new ones you can pass them as 
> named arguments.
> 
> 
> def foo(x=None, **kwargs):
> 	bar(y=2, **kwargs)
> 
> 	
> def bar(**kwargs):
> 	print(kwargs)
> 
>>>> foo(x=1, z=3)
> {'y': 2, 'z': 3}
>>>> foo(x=1, y=2, z=3)
> Traceback (most recent call last):
>   File "<pyshell#8>", line 1, in <module>
>     foo(x=1, y=2, z=3)
>   File "<pyshell#4>", line 2, in foo
>     bar(y=2, **kwargs)
> TypeError: bar() got multiple values for keyword argument 'y'

And the above error is exactly why you don't want to use named arguments 
in MI -- because you don't know in what order the methods will be 
called, you cannot know which named arguments to supply to the method 
that super() will call next.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#6642

Ethan Furman <ethan@stoneleaf.us> wrote:

>>>>> foo(x=1, y=2, z=3)
>> Traceback (most recent call last):
>>   File "<pyshell#8>", line 1, in <module>
>>     foo(x=1, y=2, z=3)
>>   File "<pyshell#4>", line 2, in foo
>>     bar(y=2, **kwargs)
>> TypeError: bar() got multiple values for keyword argument 'y'
> 
> And the above error is exactly why you don't want to use named arguments 
> in MI -- because you don't know in what order the methods will be 
> called, you cannot know which named arguments to supply to the method 
> that super() will call next.
> 

No, it just means you have to be careful how you do it: if you want to pass 
'y' to a super call then you must pop it out of the arguments. This can be 
done as easily with a named argument as with an explicit 'pop()' on kwargs.

What using a named argument does it to change the default action from 
silently overwriting any argumement passing up the chain to raising an 
error if you attempt to overwrite it without first checking whether it 
exists.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#6419

>>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 <URL: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 he clicked a link. I would *REALLY* prefer not to be 4chan-ed into jail (or fired) because I could not safely tell what a shortened URL really pointed to. Besides, shortened URLs do not live as long and are more likely to fail when people search the archives.

Ramit



Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

[toc] | [prev] | [next] | [standalone]

#6423

On Sat, May 28, 2011 at 4:10 AM, Prasad, Ramit
<ramit.prasad@jpmchase.com> 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 <URL: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 he clicked a link. I would *REALLY* prefer not to be 4chan-ed into jail (or fired) because I could not safely tell what a shortened URL really pointed to. Besides, shortened URLs do not live as long and are more likely to fail when people search the archives.

I've seen FAR more dead links than dead URL shortening services. It's
a lot more likely that the destination will go down than that the
tinyurl service will lose its data.

If you're worried about where you're going, grab a URL renderer;
TinyURL.com has "preview mode" which you can set with a cookie, and
for others, all you need is something which takes a URL off the
clipboard, requests it, gets the Location: header, and puts that on
the clipboard for you. I coded such a facility into my MUD client
(RosMud), because shortened URLs are important when lines are limited
to 80 characters (less some overhead); it'd be quite easy to build a
little Python-GTK or Python-TK app that gives you a nice window and
makes it easy.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#6391

On 26 Mai, 18:31, Raymond Hettinger <pyt...@rcn.com> 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://rhettinger.wordpress.com/2011/05/26/super-considered-super/

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 sys
def super():
    self = sys._getframe().f_back.f_locals['self']
    return __builtins__.super(type(self),self)

This way the nice Python 3.x syntax can be used in Python 2.x.


Sturla

[toc] | [prev] | [next] | [standalone]

#6393

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 sys
> def super():
>     self = sys._getframe().f_back.f_locals['self']
>     return __builtins__.super(type(self),self)
> 
> This way the nice Python 3.x syntax can be used in Python 2.x.

Python causes trouble by letting the users get at the internals, but things 
like this make it worthwhile.

	Mel.

[toc] | [prev] | [next] | [standalone]

#6396

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 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)
>> 
>> This way the nice Python 3.x syntax can be used in Python 2.x.
> 
> 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".


>>> import sys
>>>
>>> def super():
...     self = sys._getframe().f_back.f_locals['self']
...     return __builtins__.super(type(self),self)
...
>>> class A(object):
...     def __init__(self):
...         super().__init__()
...
>>> class B(A):
...     def __init__(self):
...         super().__init__()
...
>>> a = A()
>>> b = B()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __init__
  [...]
  File "<stdin>", line 3, in __init__
RuntimeError: maximum recursion depth exceeded


Do not use super(type(self), self), because it does not do what you think 
it does:

b = B() calls B.__init__(self)
... which calls super(type(self), self) = super(B, self)
... which calls A.__init__(self)
... which calls super(type(self), self) = super(B, self) *not* A
... which loops forever

type(self) does not return B inside B methods and A inside A methods, it 
returns the class of the instance.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#6399

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' !!?

    No no, you might have buggy as grubs-under-a-damp-log, or buggy as 
'moths-around-an-incandecent-lamp'  ,  or  you could have 'hot-as-hell,' 
but  'buggy-as-hell' just doesn't say what needs say'in...


... I'm just saying....




:)

[toc] | [prev] | [next] | [standalone]

#6398

sturlamolden <sturlamolden@yahoo.no> wrote:

> On 26 Mai, 18:31, Raymond Hettinger <pyt...@rcn.com> 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://rhettinger.wordpress.com/2011/05/26/super-considered-super/
> 
> 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 sys
> def super():
>     self = sys._getframe().f_back.f_locals['self']
>     return __builtins__.super(type(self),self)
> 
> This way the nice Python 3.x syntax can be used in Python 2.x.
> 
> 
Oh dear, you haven't thought this one through.

After your code above, try this:

>>> class A(object):
	def foo(self):
		print "A.foo"

		
>>> class B(A):
	def foo(self):
		print "B.foo"
		super().foo()

>>> B().foo()
B.foo
A.foo

So far so good.
Now try this:

>>> class C(B): pass

>>> C().foo()
... infinite recursion follows ...

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.


-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web