[Python-Dev] API and process questions (sparked by Claudiu Popa on 16104

[Charles-François Natali]

2014-04-28 18:29 GMT+01:00 Jim J. Jewett <jimjjewett at gmail.com>:
> On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
> <cf.natali at gmail.com> wrote:
>> Why would the user care if multiprocessing is used behind the scene?
>
> Err ... that was another set of questions that I forgot to ask.
>
> (A)  Why bother raising an error if multiprocessing is unavailable?
> After all, there is a perfectly fine fallback...
>
> On other hand, errors should not pass silently.  If a user has
> explicitly asked for multiprocessing, there should be some notice that
> it didn't happen.  And builds are presumably something that a
> developer will monitor to respond to the Exception.

The point I'm making is that he's not asking for multiprocessing, he's
asking for parallel build.
If you pass 1 (or keep the default value), there's no fallback
involved: the code should simply proceed sequentially.

> (A1)  What sort of Error?  I'm inclined to raise the original
> ImportError, but the patch prefers a ValueError.

NotImplementedError would maybe make sense.

> As Claudiu pointed out, processes=1 should really mean 1 worker
> process, which is still different from "do everything in the main
> process".  I'm not sure that level of control is really worth the
> complexity, but I'm not certain it isn't.

I disagree. If you pass job =1 (and not processes = 1), then you don't
care whether multiprocessing is available or not: you just do
everything in your main process. It would be quite wasteful to create
a single child process!

>> processes <= 0: use os.cpu_count()
>
> I could understand doing that for 0 or -1; what is the purpose of
> doing it for both, let alone for -4?
>
> Are we at the point where the parameter should just take positive
> integers or one of a set of specified string values?

Honestly, as long as it accepts 0, I'm happy.