[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