On 9/18/2014 2:15 AM, Nick Coghlan wrote:
On 18 September 2014 14:13, Steven D'Aprano steve@pearwood.info wrote:
On Wed, Sep 17, 2014 at 04:02:44PM -0700, Ram Rachum wrote:
I suggest introducing a `start=1` argument to `math.factorial`, so the result would be (the C-optimized version of) `product(range(start, x+1), start=1)`. This'll be useful for combinatorical calculations.
Then it wouldn't be the factorial function any more.
There are lots of functions which could be useful for combinatorical calculations, including !n and n!!, do you think this particular one would be of broad enough interest that it deserves to be in the standard library?
Do you know of any other programming languages which offer this "partial factorial" function in their standard library?
It's also worth noting that "pip install mpmath" will provide rising and falling factorials (http://mpmath.org/doc/current/functions/gamma.html#rising-and-falling-factor...) and a whole lot more. There's no need to add such complexity to the standard library.
However, now that CPython ships with pip by default, we may want to consider providing more explicit pointers to such "If you want more advanced functionality than the standard library provides" libraries.
Having used pip install a few times, I have begun to regard pip-installable packages as almost being extensions of the stdlib.
I think the main remaining problem is equally easy access to documentation as to the code. It would be nice, for instance, if /Doc, like /Lib, had a site-packages subdirectory with an index.html updated by pip with a link to either a package.html put in the directory or an external file, such as one at readthedocs.org. If there were something like this, I would add an item to Idle's help menu.
Yes, that may be contentious in the near term as folks argue over which "stdlib++" modules to recommend, but in some cases there are clear "next step beyond the standard library" category winners that are worth introducing to newcomers, rather than making them do their own research.
Choosing 1 *or more* packages to list should not be more contentions than choosing just 1 package to add to the stdlib.