On Tue, Sep 2, 2008 at 9:36 AM, Steven D'Aprano <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com