[Python-Dev] API and process questions (sparked by Claudiu Popa on 16104
Claudiu Popa
pcmanticore at gmail.com
Mon Apr 28 17:45:37 CEST 2014
On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <jimjjewett at gmail.com> 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. (Specifically, there is
> no explanation of the rx parameter which acts as a filter, and no
> mention that symbolic links to directories are ignored.)
>
> It is best if a commit changes one small thing at a time.
> On the other hand, Nick recently posted that the minimal overhead of a
> patch commit is about half an hour.
>
> Is that overhead enough to override the one-issue-per-patch guideline?
>
> (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 multiprocessing at all".
>
> (A) Is there a Best Practices for this situation, with two odd cases?
>
> (B) Claudiu originally copied the API from a similar APU for
> regrtest. What is the barrier for "do it sensibly" vs "stick with
> precedent elsewhere"? (Apparently regrtest treats any negative number
> as a request for the cpu_count calculation; I suspect that "-5" is
> more likely to be an escaping error for "5" than it is to be a real
> request for auto-calculation that just happened to choose -5 instead
> of -1.)
>
> (C) How important is it to keep the API consistent between a
> top-level CLI command and the internal implementation? At the the
> moment, the request for cpu_count is handled in the CLI wrapper, and
> not available to interactive callers. On the other hand, interactive
> callers could just call cpu_count themselves...
>
> (D) How important is it to maintain consistency with other uses of
> the same tool -- multiprocessing has its own was of requesting
> auto-calculation. (So someone used to multiprocessing might assume
> that "None" meant to auto-calculate, as opposed to "don't use
> multiprocessing at all.")
>
Thanks for writing this, Jim. Hopefully, the answers to these
questions will solve our disagreements
regarding the API.
More information about the Python-Dev
mailing list