RE: [Python-Dev] factory functions in the datetime module (& others)

Brian Quinlan writes:
It seems to me that the utility of subclassing certain library classes would be increased if the user could set a factory that the base class would use when creating new instances.
[...]
Any thoughts?
Hmm... I guess I'm -0 on the idea... it wouldn't really bother me, but I think it's a feature we might as well leave out.
I guess my philosophy on this comes down to a fundamental approach to subclassing basic built-in types. Types like int, float, string, datetime, list and tuple are simple, fundamental types built into Python (or its standard libraries). The usual way to use these is by composition -- create a new type that contains fields which are ints, floats, etc. And that is enough to solve nearly all problems -- in fact, up until Python 2.1, that was pretty much the only choice.
But Python wants to go the extra mile to give the programmer flexibility, so we've allowed even these basic types to be subclassed by the developer. The question is just how far we should go in supporting (and encouraging) this use. I feel that 99% of all uses of these basic types should be by composition, and only 1% (or less) by inheritance. So while I am in favor of *permitting* the subclassing, I'd be wary of tweaking other parts of the language to support it. I agree that providing customizable factory functions for these would be very helpful to users of fundamental type subclasses, but I think they are (and ought to be) a fairly small minority.
As for HOW to do it... a global factory seems like a recipe for encouraging different packages to conflict with each other -- it only works so long as only ONE module tries to install a subtype (and perhaps not even then). A per-object approach is questionable in terms of performance... and it is not acceptable (to me) to slow the performance of code which uses fundamental types by composition (essentially all Python code) for a feature like this.
Just my thoughts on the matter... I certainly agree that subclassing fundamental types is less powerful because there is no way to register some sort of factory function, but I'm not sure it's an important-enough feature to be worth the cost of supporting registrable factory functions.
-- Michael Chermside
participants (1)
-
Michael Chermside