[Tutor] method, type?

[Cameron Simpson]

On 07Jan2016 00:06, ALAN GAULD <alan.gauld at btinternet.com> wrote:
>On 06/01/16 23:00, Cameron Simpson wrote:
>
>>>> ... ensures that if you subclass the class, you automatically
>>>> get a valid constructor as well.
>>>
>>> Wouldn't it return an instance of the superclass rather than
>>> the sub class? You'd need to override it wouldn't you?
>>
>> No, when you call:
>>
>>   SubClass.from_blah(...)
>>
>> where from_blah is defined in the superclass, the leading "cls" parameter is
>> the subclass because you invoked it through the subclass,
>
>Yes, but my point is that constructors by their nature tend
>to be very  specific.

That wasn't what you said; because cls comes in as a parameter you will 
inherently get the subclass.

To your point: I don't think factory methods are necessarily very different in 
a subclass. Sometimes?  Often?  I think it is pretty variable.  In principle 
factory functions need not vary much more than any other method.  And like any 
other method, if it is special then it needs an override.

>For example a constructor that fetches data from a database
>will embed a SQL query that is table specific and so may be
>completely wrong for a sub class (unless it somehow shares
>the superclass's table).

Or if the table name (or table definition from some mapping) is a parameter of 
the subclass. I would try to make it so myself.

>Similarly reading from a network it
>will only pull the fields necessary for the superclass from
>the message. Indeed the trigger message it sends to the
>server to initiate the transfer may well have the class
>details included. So although you might wind up with an
>object whose type is subclass, its details may be totally
>wrong or even fail to operate (if the table has no
>corresponding ID for example).

Shrug. So in these cases you either need to have per-class parameters or have 
to override the factory methods as required. Like anything else. I don't think 
this is an argument against @classmethod factory functions, merely an argument 
against inattention when subclassing.

>It would certainly work for a few cases but I suspect
>most real-world constructors will fail unless overridden.
>Other class methods are much more likely to work OK. (For
>example those maintaining a cache of instances or simply
>keeping a count) I'm just dubious about constructors
>because they are so specific about where/how they obtain
>their data. (Unless you get very clever about how you
>use cls to access meta-data, or maintain some kind of
>config mapping (possibly as class attributes) to tell
>the constructor what to do.

I agree it won't also work, or work smoothly. But parameters or metadata from 
the class/subclass may be quite viable - that is the great convenience of the 
cls parameter to class methods. Once all this stuff starts getting too hard to 
look after you're probably in either don't-subclass territory, or providing 
common methods/mechanisms with mixins (i.e. a lookalike class instead of a 
subclass).

Cheers,
Cameron Simpson <cs at zip.com.au>