[Python-ideas] Factory functions (was: RE: time.wallclock() or other similar stuff)

[Nick Coghlan]

On Thu, Nov 4, 2010 at 1:08 AM, Guido van Rossum <guido at python.org> wrote:
> Indeed; the intention was that it should be possible to replace the
> various lock classes with built-in objects without having to worry
> about continuing subclasses. While this was done before built-in
> objects could be subclassed, even today I still like to prevent
> subclassing the lock classes since the ability to subclass still
> constrains the implementation of the built-in type somewhat. I think
> it's more important to have the possibility to switch in a faster
> platform-specific lock implementation. I do admit that so far this
> hasn't happened...

I think the adventures with dict() over the years show pretty clearly
the kind of care the superclass has to take to properly allow
subclassing (i.e. frequently checking the actual class before taking
shortcuts that bypass potential overrides in subclasses). It's not
impossible, obviously, but it does require extra care and attention in
the superclass. Using a factory function instead is a very clear way
to say "no, I'm not making any promises about your ability to inherit
useful functionality from this implementation". Historically, you
could have your cake and eat it too by providing a Mixin class to help
implementation of alternative approaches, as well as the original
factory function. These days, ABCs are probably a better choice for
the niche previously occupied by the Mixin classes.

The cases that mildly irritate me are the factory functions that are
*named* with CamelCase as if they were classes, just because they're
surprising when I find out the name gives the wrong impression of the
metaclass involved (i.e. a function rather than a type).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia