On Mon, 16 Feb 2015 08:14:00 -0500, Roy Smith <r...@panix.com> wrote:

>In article <mpg.2f4beb20faeff072989...@nntp.aioe.org>,
> Mario Figueiredo <mar...@gmail.com> wrote:
>
>> It's not been an easy ride trying to decide whether or not to use super. 
>> I started learning python from a Mark Lutz book that advised me against 
>> it. 
>
>I'm curious, what were the arguments against it?

The following is quoted from Learning Python, 5th Edition:

>Java programmers may especially be interested to know that Python also has a 
>super
>built-in function that allows calling back to a superclass’s methods more 
>generically—
>but it’s cumbersome to use in 2.X; differs in form between 2.X and 3.X; relies 
>on unusual
>semantics in 3.X; works unevenly with Python’s operator overloading; and does 
>not
>always mesh well with traditionally coded multiple inheritance, where a single 
>superclass call won’t suffice.
>
>In its defense, the  supercall has a valid use case too—cooperative same-named 
>method
>dispatch in multiple inheritance trees—but it relies on the “MRO” ordering of 
>classes,
>which many find esoteric and artificial; unrealistically assumes universal 
>deployment
>to be used reliably; does not fully support method replacement and varying 
>argument
>lists; and to many observers seems an obscure solution to a use case that is 
>rare in real
>Python code.
>
>Because of these downsides, this book prefers to call superclasses by explicit 
>name
>instead of  super, recommends the same policy for newcomers, and defers 
>presenting
>supe until Chapter 32.
> [...]
>And to any Java programmers in the audience: I suggest resisting the 
>temptation to use
>Python’s  superuntil you’ve had a chance to study its subtle implications. 
>Once you
>step up to multiple inheritance, it’s not what you think it is, and more than 
>you probably
>expect. The class it invokes may not be the superclass at all, and can even 
>vary per
>context. Or to paraphrase a movie line: Python’s superis like a box of 
>chocolates—you
>never know what you’re going to get!

Later, in chapter 32 where super is finally introduced, you can read
the following:

>As noted in Chapter 28 and Chapter 29, Python has a superbuilt-in function 
>that can
>be used to invoke superclass methods generically, but was deferred until this 
>point of
>the book. This was deliberate—because  superhas substantial downsides in 
>typical
>code, and a sole use case that seems obscure and complex to many observers, 
>most
>beginners are better served by the traditional explicit-name call scheme used 
>so far. See
>the sidebar  “What About super?” on page 831in  Chapter 28for a brief summary 
>of
>the rationale for this policy.
>The Python community itself seems split on this subject, with online articles 
>about it
>running the gamut from “Python’s Super Considered Harmful” to “Python’s super()
>considered super!”
>Frankly, in my live classes this call seems to be most often of interest
>to Java programmers starting to use Python anew, because of its conceptual 
>similarity
>to a tool in that language (many a new Python feature ultimately owes its 
>existence to
>programmers of other languages bringing their old habits to a new model). 
>Python’s
>superis not Java’s—it translates differently to Python’s multiple inheritance, 
>and has
>a use case beyond Java’s—but it has managed to generate both controversy and
>misunderstanding since its conception.
>
>In its defense, this call does have a valid use case too—cooperative 
>same-named method
>dispatch in diamond multiple inheritance trees—but it seems to ask a lot of 
>newcomers.
>It requires that  superbe used universally and consistently (if not 
>neurotically), much
>like  __slots__discussed earlier; relies on the arguably obscure MRO algorithm 
>to order
>calls; and addresses a use case that seems far more the exception than the 
>norm in
>Python programs. In this role, superseems an advanced tool based upon esoteric 
>principles,
>which may be beyond much of Python’s audience, and seems artificial to real
>program goals. That aside, its expectation of universal use seems unrealistic 
>for the vast
>amount of existing Python code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to