[Python-Dev] Confirming status of new modules in 3.4

Guido van Rossum guido at python.org
Sun Mar 16 00:27:59 CET 2014


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

> Guido van Rossum <guido at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140315/ffdbae72/attachment.html>


More information about the Python-Dev mailing list