On Thu, Nov 4, 2010 at 1:08 AM, Guido van Rossum
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@gmail.com | Brisbane, Australia