[Tutor] method, type?

[Alan Gauld]

On 08/01/16 04:24, Steven D'Aprano wrote:

> I maintain that "constructor" for the most part has to be understood of 
> a statement of intention, not a hard definition. Apart from __new__ 
> itself, which genuinely is special, "constructor" in a language like 
> Python refers to the intention of creating new instances, as opposed to 
> "doing some work".

I think the question here is whether we are talking about the
specifics of how Python does things or about the meaning of
the terms in the wider OOP community. I'd argue that in wider OOP
circles constructor is a much more specific term but in Python
it is more about intent. (The init case is a good example where
we generally, and sloppily, refer to init as a constructor when
in fact its only an initialiser)

>From the point of view of the tutor list we have a slight dilemma
because we are here to teach both Python the language as well as
wider programming skills.

A thread like this exposes where Python's specific way of doing
things is at odds with the wider practice and terminology and
probably confuses noobies (sorry folks) but at the same time
throws up a lot of interesting details about just how Python
does its particular brand of OOP magic.

> class MyClass:
>     def __new__(cls):
>         return "Surprise!"
> 
> Surprising though this is, it is actually allowed,

And again this is one of the differences between Python and
the vast majority of OOP languages.  In most cases constructors
are not allowed to explicitly return anything because the language
implicitly returns an instance (or occasionally throws an
exception). But that's because those languages have a very
specific meaning for constructor, often with different syntax
or idioms from normal methods. Whereas, as you've pointed
out, Python's construction mechanism is much more open and
consistent making the meaning of 'constructor' more loosely
defined.

> (1) __new__ is the default constructor;
> 
> (2) __init__ is the initialiser, but sometimes we're lazy and call it 
> the constructor;
> 
> (3) If you see a CLASS method called "from_foo" or similar, which 
> returns an instance of the class, that's probably an alternate 
> (non-default) constructor;
> 
> (4) But we usually don't count methods which take an instance of the 
> class, and transform or copy them in some way as "constructors" even if 
> they do in fact construct a new instance.

Yep. I'll buy that for when we are talking about Python
In the wider OOP world there are more definite distinctions
in the terms.

The good news is that for working programmers most of
these distinctions are subtle enough, or theoretical enough,
not to matter. You create objects by either
a) calling an established default constructor protocol or
b) by invoking a class method or factory function.

Coming back to the original theme of this thread it looks like
we are coming to the conclusion that, at least when applied
to objects, factory methods/functions can also be called
constructors. (And from my foray into the "named constructor"
idiom of C++ those guys are allowing such latitude in terminology
too.) So the only place where confusion would exist is in those
languages (such as objective C or Object Pascal) where constructor
or 'factory method' have a specific syntax and meaning in the
language.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos