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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor