Flagging classes as not intended for direct initialization

[Mario Figueiredo]

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

>In article <MPG.2f4beb20faeff0729896ba at nntp.aioe.org>,
> Mario Figueiredo <marfig at 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.