Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #65150 > unrolled thread

Re: __init__ is the initialiser

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: __init__ is the initialiser Ned Batchelder <ned@nedbatchelder.com> - 2014-01-31 18:43 -0500

#65150 — Re: __init__ is the initialiser

On 1/31/14 6:05 PM, Ben Finney wrote:
> Ned Batchelder <ned@nedbatchelder.com> writes:
>
>> On 1/31/14 2:33 PM, Mark Lawrence wrote:
>>>   From http://docs.python.org/3/reference/datamodel.html#object.__init__
>>> […]
>>> Should the wording of the above be changed to clearly reflect that
>>> we have an initialiser here and that __new__ is the constructor?
>>
>> I'm torn about that. The fact is, that for 95% of the reasons you want
>> to say "constructor", the thing you're describing is __init__.
>
> I assume the “95%” figure is made up. Whose wants are you divining, here?
>
>> Most classes have __init__, only very very few have __new__.
>
> Yes, this is true, and I agree it is a major factor in the confusion:
> the term “constructor” is commonly encountered in discussion of classes,
> and in Python, the method “__init__” is commonly encountered. It is a
> natural mistake to think Python names its constructor “__init__”, since
> most classes don't define “__new__”.
>
>> The sense that __new__ is the constructor is the one borrowed from C++
>> and Java: you don't have an instance of your type until the
>> constructor has returned. This is why __init__ is not a constructor:
>> the self passed into __init__ is already an object of your class.
>
> A more salient reason, I think, is that “constructor” entails that the
> function will return the instance. This is another important reason why
> “__init__” is not a constructor: it does not return the instance.
>
>> But that distinction isn't useful in most programs. The thing most
>> people mean by "constructor" is "the method that gets invoked right at
>> the beginning of the object's lifetime, where you can add code to
>> initialize it properly." That describes __init__.
>
> Here we disagree. I think the meaning “… and that returns the new
> instance” is entailed in the meaning of “constructor”.
>
>> Why can't we call __init__ the constructor and __new__ the allocator?
>
> Because those terms already have meanings, and “__new__” fits the
> meaning of “constructor” better.
>

You say these terms already have meanings, and that constructor means a 
function that returns the new instance.  Then your word "constructor" 
isn't the same as C++'s word "constructor"?  Those don't return the 
instance.   Neither do Java constructors.  In terms of the code 
developers actually write in __init__, it looks an awful lot like a C++ 
or Java constructor, and serves precisely the same purpose.  The fact 
that the underlying mechanisms are slightly different seems like an odd 
reason to force a difference in names.

My point is that often the same word in two different programming 
languages won't have a precise mapping.  "Variable" is a common example. 
  Python ints are different than C ints, yet we call them both ints.  C 
and Java and Python all have "for" statements.  We didn't insist on a 
different keyword just because the semantics are different.

There are enormous differences between Python functions, C functions, 
Java functions, and Haskell functions.  But they serve similar roles in 
the programmer's toolkit, and we use the same name for them.

I'm not hoping to change any official terminology. I just think that 
calling __init__ anything other than a constructor is confusing 
pedantry.  It is a constructor, and Python constructors work differently 
than those in C++ and Java.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web