On 07Jan2016 00:06, ALAN GAULD <alan.ga...@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 <c...@zip.com.au>
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
