Greg Ewing wrote:
> Steven D'Aprano wrote:
>> Why not expose the class directly, instead of making it private and
>> then exposing it via a factory function that does nothing else?
>
> This option would also have the advantage of not
> changing the API (unless there's code out there that
> actually depends on them *not* being classes, and
> that seems rather unlikely).
The multiprocessing implementation currently appears to have an annoying
circular import involving the multiprocessing package and the
_multiprocessing extension module - the factory functions in
multiprocessing.__init__ currently delay some of the relevant imports
long enough to keep any problems from actually occurring.
At some point that circular import should probably be eliminated (e.g.
via a _mp_bootstrap module), but until that happens at least some of the
factory functions in multiprocessing are actually required in order for
it to be possible to import the package at all.
And, as Guido already noted, leaving them as factory functions with
private implementations means users can't come to rely on the objects
being subclassable, and thus potentially allows more efficient
implementations (e.g. using near native locking implementations directly).
The only unfortunate aspect of the API is that the current names suggest
that these are factory functions rather than classes - if it hadn't been
for that, the question would have never even been raised. Since we
already have guidelines in place for dealing with ordinary API renames,
this is no longer something that strikes me as particularly urgent in
the 2.6/3.0 timeframe.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
