On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <jimjjew...@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. _______________________________________________ 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