[Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

Nick Coghlan ncoghlan at gmail.com
Mon Sep 1 15:24:02 CEST 2008


I've been taking a close look at the API for multiprocessing and
threading, and have discovered a somewhat strange pattern that occurs
multiple times in both interfaces: factory functions with names that
start with a capital letter so they look like they're actually a class.

At first I thought it was a quirk of the multiprocessing implementation,
but then I discovered that the threading module also does it for all of
the synchronisation objects as well as threading.Timer, with examples like:

  def Event(*args, **kwds):
    return _Event(*args, **kwds)

Is this just intended to discourage subclassing? If so, why give the
misleading impression that these things can be subclassed by naming them
as if they were classes?

How should this be handled when it comes to the addition of PEP 8
compliant aliases? Add aliases for the factory functions that start with
a lower case letter, but otherwise leave the structure of the modules
unchanged? Or should the trivial functions like the one above be dropped
and made direct aliases for the classes they are currently wrapping?

Option 1 has the virtue of being perfectly backwards compatible in the
threading case, while option 2 is a little riskier, so I'm inclined to
go with option 1 (keeping the factory functions, but giving them
non-class like names in the case of multiprocessing, or aliases in the
case of threading).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
            http://www.boredomandlaziness.org


More information about the Python-Dev mailing list