On 07/01/16 23:19, Steven D'Aprano wrote: > "Factory methods" just means a method which you, the creator or author, > thinks of as a factory. What's a factory? A function or method which > takes a bunch of arguments and creates something useful.
In classic OOP a factory method is more specific than that. It's a method that returns an instance and is part of the language definition in several older OOP languages - Objective C being the best known. A factory function however is any old function that returns any old kind of object/record/function or whatever. > more "Enterprisey" and Java-esque than it need be. It pre-dates Java by a long way and has little to do with anything enterprisey. (Except that enterprises tend to build/own real physical factories! :-) >> Alan Gauld indicates that as initially written (without >> '@staticmethod') "it is not" ?a method/function? > > With respect to Alan, I think he is factually wrong. Me too. Until your first post about this I hadn't realized that v3 makes them all functions. So I saw the original code as being a method definition (it had a 'self' parameter, but it was treated as text which would cause it to fail if used as a method. And because it was defined as a method it couldn't be used as a function.) It seems that's no longer true in v3 and I'll need to do some playing around to better understand the significance of the change. >> He recommends making it a factory >> function (defined at the module level, outside the class.) > > That's a matter of personal taste, and one which I happen to disagree It was based on what I perceived as the Python idiomatic style. It seems there are more classmethod factories around than I thought so, on that basis, I'd revert to classmethod as the preferred style. >> The table provided by Peter Otten (very helpful:) >> ----------------------------------------------------------------- >> invoked with | @staticmethod | @classmethod | no decorator >> ------------------------------------------------------------------ >> class | args unchanged | class as 1st arg | args unchanged >> instance | args unchanged | class as 1st arg | inst as 1st arg >> ------------------------------------------------------------------- I missed this one somehow. Nice table Peter. My only point of difference here, I think, is the definition of a constructor. I consider a constructor to be the creator of object instances, which makes the only default Python constructor the __new__() since the __init__() is only an initializer. And most factory methods simply use the default __new__() for construction then provide alternative initialization. However, there was one post that suggested that __new__() could be bypassed - although it still seemed to rely on an explicit call to object.__new__() So I need to do yet more reading on that score too. -- 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
