Python constructors have particular semantics, and ‘Foo.init’ doesn't qualify

Wed Dec 14 23:14:18 EST 2016

Ben Finney wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>> On Tue, Dec 13, 2016 at 10:17 AM, Ben Finney <ben+python at benfinney.id.au>
>> wrote:
>> > If the differences didn't matter I would agree that “overly
>> > pedantic” is fair. But those differences trip up newcomers. Thinking
>> > of ‘Foo.__init__’ leads people to wonder where the ‘self’ attribute
>> > came from – am I not meant to be constructing it? — and to attempt
>> > to return that instance. And when the time comes to lean about
>> > ‘__new__’ the confusion continues, because the newcomer has been
>> > told that something *else* is the constructor, so what's this?
>>>> In JavaScript [different semantics apply].
>>>> Ultimately, every language has slightly different semantics […], so
>> you have to learn that the "constructor" might have slightly different
>> semantics.

Actually, that is an inverse semantic fallacy. There *is* always *some* 
common semantics to a the same term used in different domains; that is *why* 
it is used across domains (here: across object-oriented programming 
languages). The common semantics here appears to be, as I substantiated by 
the FOLDOC reference, that a constructor initializes an object/instance.
“construct” does _not_ mean the same as “create” (make); understood 
literally, it means “heap together”, “build” (from Latin «construo», from 
«com» “together” + «struo» “I heap up, pile”). A “constructor” is then the 
person or (here) the thing that “heaps together”. ISTM that it “heaps 
together” the properties/attributes so that the object can be useful.
This is the same in Python as in several other OOPLs inasfar as that I can 
use super() or the superclass’ name to call the parent …what? – yes, the 
parent *constructor* of the class, i.e. the superclass’ (or in python, one 
of the superclass’) *constructor* from a class’ *constructor* (yes, I 
insist; see below) to initialize inherited attributes.
> Please read again the message you extracted that quote from. I already
> said I'm not claiming some other programming language's semantics should
> dictate Python's.
>>> What I'm saying is that in Python, there *already are* different
> semantics for a constructor, and they don't match the semantics of
> ‘Foo.__init__’.

Yes, *you* are saying that.

> In Python, a constructor for a class is a class method.

Says who, *you*?
> ‘Foo.__new__’ is a constructor. ‘Foo.__init__’ is an instance method, so
> it's not a constructor.

According to <https://docs.python.org/3/tutorial/classes.html#method-objects>, “Foo.__init__” is _not_ an instance method. Were it an instance 
method, the following would not happen:
| >>> class Foo:
| ... def __init__ (self):
| ... pass
| ...
| >>> Foo.__init__.__self__
| Traceback (most recent call last):
| File "<stdin>", line 1, in <module>
| AttributeError: 'function' object has no attribute '__self__'

Because “Instance method objects have attributes, too: m.__self__ is the 
instance object with the method m() […]”.
“Ex falso quodlibet”, “wishful thinking”, and “circular reasoning” come to 
mind here: *You* say that a constructor is a class method in Python, then 
*you* define __init__() to be an instance method, therefore __init__() 
*cannot* qualify anymore as a constructor. So your wish is fulfilled, *far 
from reality*.
[If one would instantiate Foo, *then* the __init__() method of the instance 
would be an instance method (which is tautological):
| >>> Foo().__init__.__self__
| <__main__.Foo object at 0x7f86d73e8ef0>

]

> In Python, a constructor for a class makes the instance where it didn't
> already exist. ‘Foo.__new__’ is a constructor. ‘Foo.__init__’ requires
> the instance to already be constructed, so it's not a constructor.

You are also limiting the meaning of “constructor” in OOP to “create the 
instance” so that __init__() does not fit your definition of what is a 
constructor in Python in that regard as well. But as I showed, not only 
does “constructor” not need to mean that, it can also mean much more than 
that.
So your reasoning is doubly invalid.

> I'm showing that Python classes *already have* constructors,

By *your* definition that you have *construed* (no pun intended) to fit your 
argument.
> and ‘Foo.__init__’ doesn't qualify because it doesn't have the semantics 
> of Python constructors.

By *your* definition. That does not mean that your definition is correct, 
or that your reasoning is valid.
-- 
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

Python constructors have particular semantics, and ‘Foo.__init__’ doesn't qualify

Python constructors have particular semantics, and ‘Foo.init’ doesn't qualify