Billy Mays wrote:
> I read this when it was on HN the other day, but I still don't see what
> is special about super(). It seems (from your post) to just be a stand
> in for the super class name? Is there something special I missed?
>
Consider any diamond hierarchy:
class Base(object): pass
Summary: super(cls, data) in a method gets you the "next" handler
for a given class "cls" and an instance "data" that has derived
from that class at some point. In Python 2 you must spell out the
names of the class and instance (normally "self") explicitly, while
Python 3 grabs, at compile time, t
On Wed, Jun 1, 2011 at 10:46 AM, Billy Mays wrote:
> What it does is clear to me, but why is it interesting or special isn't.
> This looks like a small feature that would be useful in a handful of cases.
Well, I agree with you there. The complexity introduced by super
typically outweighs the be
On Tue, May 31, 2011 at 8:44 PM, Raymond Hettinger wrote:
> I've tightened the wording a bit, made much better use of keyword
> arguments instead of kwds.pop(arg), and added a section on defensive
> programming (protecting a subclass from inadvertently missing an MRO
> requirement). Also, there
On 6/1/2011 12:42 PM, Ian Kelly wrote:
On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays wrote:
I read this when it was on HN the other day, but I still don't see what is
special about super(). It seems (from your post) to just be a stand in for
the super class name? Is there something special I mis
On Wed, Jun 1, 2011 at 7:03 AM, Billy Mays wrote:
> I read this when it was on HN the other day, but I still don't see what is
> special about super(). It seems (from your post) to just be a stand in for
> the super class name? Is there something special I missed?
It's not a stand-in for the su
On 5/31/2011 10:44 PM, Raymond Hettinger wrote:
I've tightened the wording a bit, made much better use of keyword
arguments instead of kwds.pop(arg), and added a section on defensive
programming (protecting a subclass from inadvertently missing an MRO
requirement). Also, there is an entry on how
Raymond Hettinger writes:
> Any further suggestions are welcome.
I am impressed by your optimistic outlook:
For reorderable method calls to work, the classes need to be
designed cooperatively. This presents three easily solved practical
issues[…]
:-)
It's a good document, and I'm
I've tightened the wording a bit, made much better use of keyword
arguments instead of kwds.pop(arg), and added a section on defensive
programming (protecting a subclass from inadvertently missing an MRO
requirement). Also, there is an entry on how to use assertions to
validate search order requir
