Live data from Hacker News

Wield Python's super() like a Jedi

rhettinger.wordpress.com

61–67 of 67 posts

Re: Wield Python's super() like a Jedi

#61
post #43

I didn't see it linked in the article nor mentioned here already but several of the problems with `super` have been discussed in "Python's Super is nifty, but you can't use it"[1] for quite some time. [1]: http://fuhm.net/super-harmful/

That article is about Python 2's super, which is a different beast. Lessons were learnt in the design of Python 3's version.

Not really. The only thing that changed about super in Python 3 is that you can call it with no arguments, which is just a short-hand for the way it was already used in Python 2. Everything in that article applies equally to both Python versions.

Re: Wield Python's super() like a Jedi

#62

It seems to me that the example of combining built-in dictionary classes is naively optimistic. For starters, OrderedDict, as it happens, does not use super! It calls the dict super-class methods directly. Since dict happens to be the next class in the MRO, this doesn't really matter for the purpose of this example, but I can envision a scenario where some plucky programmer inherits from both OrderedCounter and some…

why would you have to subclass DefaultOrderedCounter again in order to add in the missing method? Though I agree there's something annoying going on there with the multiple inheritence.

I mistyped. I meant "subclass OrderedCounter to add in the __missing__ method".

Re: Wield Python's super() like a Jedi

#63
post #51

Earlier quoted context omitted.

One of the reasons I'm starting to love Go more than Python. In Go something like super() is superfluous.

The only reason why you don't need super in Go is because you cannot embed multiple interfaces except if their sets of methods are disjoint. This eliminates super's job of allowing programmers to differentiate between base classes with conflicting method implementations. Without this, Go requires you to design your class hierarchy in a way that is cleaner, but the super concept is still not superfluous -- because you…

Sigh. No, that is not at all how super works in Python. The equivalent code to that Go function would be:

  def read_and_write(self):
      Reader.read(self)
      Writer.write(self)
That is, if you want to get at a particular superclass implementation, then you just call it directly. super() is used when you're not calling a particular superclass, instead relying on Python to compute the correct "next method" for you.

"super(Reader).read()", if you actually try it, will just result in an AttributeError. This is because super(Reader) returns an unbound super object, not a bound super object that you can actually dispatch from. Why this advanced usage might be useful is beyond the scope of this thread, but if you're curious then just google for python unbound super and hit the Feeling Lucky button.

Re: Wield Python's super() like a Jedi

#64

tl;dr Just looks like super/parent like in other languages. Did i miss something from not reading this?

> Did i miss something from not reading this? Everything? Mostly the part where, Python being an MI language, a given class A has multiple parents. And these parents are a sequence, not a set, which define a Method Resolution Order, and that method resolution order usually isn't breadth-first either, so Python's super is a graph walker. And because it's explicit, any node in the graph can stop the walking. This means…

Thanks for the short explanation. I totally forget about python being MI.

Re: Wield Python's super() like a Jedi

#65
post #48

tl;dr Just looks like super/parent like in other languages. Did i miss something from not reading this?

You didn't miss as much as others seem to think. Nothing here changes the fact that it subverts the object model and overuse causes kudzu.

Yeah, OO is too hard.

Re: Wield Python's super() like a Jedi

#66

Earlier quoted context omitted.

The only reason why you don't need super in Go is because you cannot embed multiple interfaces except if their sets of methods are disjoint. This eliminates super's job of allowing programmers to differentiate between base classes with conflicting method implementations. Without this, Go requires you to design your class hierarchy in a way that is cleaner, but the super concept is still not superfluous -- because you…

Sigh. No, that is not at all how super works in Python. The equivalent code to that Go function would be: def read_and_write(self): Reader.read(self) Writer.write(self) That is, if you want to get at a particular superclass implementation, then you just call it directly. super() is used when you're not calling a particular superclass, instead relying on Python to compute the correct "next method" for you. "super(Read…

Yeah you're right, I was mistaken. super uses the MRO of the first argument, or inspects the stack if none is given.

BTW your sighing is not necessary.

Re: Wield Python's super() like a Jedi

#67

Earlier quoted context omitted.

Sigh. No, that is not at all how super works in Python. The equivalent code to that Go function would be: def read_and_write(self): Reader.read(self) Writer.write(self) That is, if you want to get at a particular superclass implementation, then you just call it directly. super() is used when you're not calling a particular superclass, instead relying on Python to compute the correct "next method" for you. "super(Read…

Yeah you're right, I was mistaken. super uses the MRO of the first argument, or inspects the stack if none is given. BTW your sighing is not necessary.

I apologize. It was late, and my supply of patience for the day was exhausted.
Post reply on HN