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

[Guido van Rossum]

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/)