[Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing (original) (raw)

Guido van Rossum guido at python.org
Tue Sep 2 18:51:04 CEST 2008

On Tue, Sep 2, 2008 at 9:36 AM, Steven D'Aprano <steve at pearwood.info> wrote:

On Mon, 1 Sep 2008 11:24:02 pm Nick Coghlan wrote:

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)

Can anyone explain why those factory functions exist at all? They don't seem to do anything. Why not expose the class directly, instead of making it private and then exposing it via a factory function that does nothing else? Never mind whether or not the factory functions should start with an uppercase letter or not. Why are they even there?

Perhaps I'm missing some subtle (or even not-so-subtle) advantage, but it seems rather silly to me, as silly as this: f = lambda x: function(x) # better written as f = function And yet threading.py has at least six examples just like that. What am I missing?

I take full responsibility. This started out as an experiment in API design, where I tried to make things look as much like the similar Java API as possible (I didn't want to invent yet anotherwobbly wheel). I specifically wanted these not to be classes so that people wouldn't start subclassing them. At the time PEP-8 wasn't well established (if at all) and I wanted the factory functions to look like classes. I think in 2.7 / 3.1 we can change the factory functions to conform to PEP-8 (leaving the old names in for a couple of release). I still want the classes to be private, so that it's safe to replace them with more efficient implementations on some platforms without having to worry about subclasses.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list