2014-04-28 18:29 GMT+01:00 Jim J. Jewett <jimjjew...@gmail.com>: > On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali > <cf.nat...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com