On Sat, Mar 15, 2014 at 2:44 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:

Guido van Rossum <guido@python.org> writes:
> This downside of using subclassing as an API should be well known by now
> and widely warned against.

It wasn't known to me until now. Are these downsides described in some
more detail somewhere?

So far I have always thought that, as long as I avoid using private
attributes, subclassing was supported like any other use of the API.

Googling for things like "containment vs. inheritance" finds a wealth of articles explaining the issues. Apparently even the classic GoF patterns book prefers containment.

The problem with subclassing is that it tends to create tighter coupling between provider and consumer of an API. I believe this is due to the addition of "protected" APIs that are supposedly okay to use for subclasses but not for other users. If you can completely avoid those I suppose you'd be okay, but note that my remark was sparked by a proposal to create just such a protected API (_poller).

Additionally, a subclass and its base class share the same namespace, so a method or attribute defined by a subclass may get in the way of something with the same name added in a new version of the base class.

The main area where I think subclassing is fine is when base class and subclasses are all part of the same package/module, so their evolution is controlled by the same team. I suppose there are also some good uses for abstract base classes that avoid the above issues.

--
--Guido van Rossum (python.org/~guido)