(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.") -jJ _______________________________________________ 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
