On Tue, Apr 29, 2014 at 11:11 PM, Charles-François Natali
wrote:
> 2014-04-28 21:24 GMT+01:00 Claudiu Popa :
>> [...]
>>
>> If anyone agrees with the above, then I'll modify the patch. This will
>> be its last iteration, any other bikeshedding
>> should be addressed by the core dev who'll apply it
2014-04-28 21:24 GMT+01:00 Claudiu Popa :
> [...]
>
> If anyone agrees with the above, then I'll modify the patch. This will
> be its last iteration, any other bikeshedding
> should be addressed by the core dev who'll apply it.
I'm perfectly happy with those proposals.
On 28 Apr 2014 16:19, "Ezio Melotti" wrote:
>
> On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett
wrote:
> > (1) Should fixes to a docstring go in with a patch, even if they
> > aren't related to the changing functionality?
> >
> > [...]
> >
> > It is best if a commit changes one small thing at a t
On Mon, 28 Apr 2014 23:24:16 +0300, Claudiu Popa wrote:
> - Will raise NotImplementedError if multiprocessing can't be used
> (when `workers` equals to 0 or > 1)
I think the most common use case for this ability will be "run with
the appropriate number of processes for the system I'm on", where
'
On 4/28/2014 4:24 PM, Claudiu Popa wrote:
This issue raised too much bikeshedding. To wrap it up, I'll modify
the patch with the following:
- processes renamed to workers
- `workers` defaults to 1
- When `workers` is equal to 0, then `os.cpu_count` will be used
- When `workers` > 1, multiple pro
This issue raised too much bikeshedding. To wrap it up, I'll modify
the patch with the following:
- processes renamed to workers
- `workers` defaults to 1
- When `workers` is equal to 0, then `os.cpu_count` will be used
- When `workers` > 1, multiple processes will be used
- When `workers` == 1, r
On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett wrote:
> (1) Should fixes to a docstring go in with a patch, even if they
> aren't related to the changing functionality?
>
> [...]
>
> It is best if a commit changes one small thing at a time.
> On the other hand, Nick recently posted that the minim
In article
,
"Jim J. Jewett" wrote:
> 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.
For regrtest,
2014-04-28 18:29 GMT+01:00 Jim J. Jewett :
> On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
> 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 multip
On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali
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 perfec
And incidentally, I think that the argument *processes* should be
renamed to *workers*, or *jobs* (like in make), and any mention of
multiprocessing in the documentation should be removed (if any):
multiprocessing is an implementation detail.
When I type:
make -jN
I don't really care that make is
>> (2) The patch adds new functionality to use multiple processes in
>> parallel. The normal parameter values are integers indicating how
>> many processes to use. The parameter also needs two special values --
>> one to indicate "use os.cpu_count", and the other to indicate "don't
>> use multip
On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett wrote:
> (1) Should fixes to a docstring go in with a patch, even if they
> aren't related to the changing functionality?
>
> Bytestring compilation has several orthogonal parameters. Most -- but
> not all -- are documented in the docstring. (Speci
On Mon Apr 28 2014 at 11:32:58 AM, Jim J. Jewett
wrote:
> (1) Should fixes to a docstring go in with a patch, even if they
> aren't related to the changing functionality?
>
It should probably be its own commit.
>
> Bytestring compilation has several orthogonal parameters. Most -- but
> not a
(1) Should fixes to a docstring go in with a patch, even if they
aren't related to the changing functionality?
Bytestring compilation has several orthogonal parameters. Most -- but
not all -- are documented in the docstring. (Specifically, there is
no explanation of the rx parameter which acts
15 matches
Mail list logo
