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

Michael Chermside mcherm at mcherm.com
Mon May 24 09:07:19 EDT 2004


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




More information about the Python-Dev mailing list