Multiple inheritance, super() and changing signature

[Random832]

On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
> On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
> 
> > On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> >> (Note that ‘__init__’ is not a constructor, because it operates on the
> >> *already constructed* instance, and does not return anything.
> > 
> > Believe it or not, that *is* what “constructor” means in every OO
> > language. 
> 
> I don't believe it. 
> 
> C# is an OO language, and it distinguishes constructors and initialisers:
> 
> https://msdn.microsoft.com/en-us/library/bb397680.aspx

The methods described on that page as "constructors" operate *precisely*
as Lawrence said.

An "initializer" as that page discusses is not a method but is a kind of
expression, with no analogue in Python, which compiles to multiple
operations and 'returns' a value to be assigned to a variable. A
hypothetical Python analogue to the C# expression 'new c() { a = 1, b =
2 }', an "initializer", might compile to the following bytecode:
LOAD_GLOBAL (c); CALL_FUNCTION 0; DUP_TOP; LOAD_CONST (1); ROT_TWO;
STORE_ATTR (a); DUP_TOP; LOAD_CONST (2); ROT_TWO; STORE_ATTR (b); i.e.
yielding into the surrounding expression context an instance of type 'c'
which has been constructed and then subsequently had two of its
attributes (in C#'s case, fields and/or properties) set (or .Add methods
called, in the case of collection initializers)

> > Technically it should be called the “initializer”, but 
> > “constructor” is the accepted term for the special method that is called
> > to initialize a newly-allocated class instance.
> 
> Not in Python circles it isn't.

I suspect that the basis on which people refuse to accept it is a
(completely incorrect) sense that "constructor" has an inherent meaning
as allocating a new object, when no-one's been able to document that it
is used *anywhere*, Python or otherwise, in that sense. (I also
inherently dislike the notion that any given language community should
get to unilaterally decide, even if there were any such agreement, what
a term means, denying us a common way to talk about concepts shared
between languages to no benefit)

Your "python circles" seem to consist of people who are ignorant of how
other languages actually work and who want to believe that python is
special [i.e. in this case that python's __init__ is somehow different
in operation from C++ or C#'s or Java's constructors] when it is not. I
think it's more or less the same crowd, and the same motivation, as the
"python doesn't have variables" folks, and should be likewise ignored.

> But since the constructor/initialiser methods are so closely linked, many
> people are satisfied to speak loosely and refer to "the constructor" as
> either, unless they specifically wish to distinguish between __new__ and
> __init__.

Where there is looseness, it comes from the fact that because __init__
is always called even if __new__ returns a pre-existing object people
often place code in __new__ which mutates the object to be returned,
acting somewhat like a traditional constructor by assigning attributes
etc.

But it is __init__ that acts like the thing that is called a constructor
in many languages, and no-one's produced a single example of a language
which uses "constructor" for something which allocates memory.

Now, where "constructor" *does* often get misused, it is for the
new-expression in other languages, and for type.__call__ in Python,
people speak as if they're "calling the constructor" (rather than
calling something which ultimately calls both __new__ and __init__). But
from a class-definition perspective, __init__ is the one and only thing
that should be called a constructor.

The fact that many languages don't have any way to override object
allocation, and therefore no analogue to __new__, also contributes to
this conclusion. In these languages, new-expressions (or the like) are
the only way to call a constructor, so people associate object
allocation with constructors.