[Python-ideas] Introduce `start=1` argument to `math.factorial`

Georg Brandl g.brandl at gmx.net
Thu Sep 18 21:01:31 CEST 2014


On 09/18/2014 07:01 PM, Andrew Barnert wrote:

>> 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.
> 
> There are plenty of clear winners that are worth introducing to newcomers,
> but aren't the next step beyond a particular module. In fact, I think that's
> the case for _most_ of them. pytz, dateutil, requests, urllib3, pycurl, and
> maybe more-itertools or blist and a couple of math libs, the main things
> people are going to want to find (not counting frameworks like Django or
> Scrapy or PySide) are things like NumPy, Pandas, Pillow, PyYAML, lxml,
> BeautifulSoup, PyWin32, PyObjC, pyparsing, paramiko, … and where do any of
> those go?
> 
> Does this mean we have to add pages in the docs for things the stdlib doesn't
> do, just to provide external references? Or turn the chapter-header blurbs
> into real pages? Or reorganize the docs more dramatically? Or just leave out
> some of the most prominent and useful libraries on PyPI just because they
> don't fit anywhere, while mentioning others? 

I don't think the docs should generically recommend external packages, except
for cases like "if you need this functionality that exists only in 3.5 and
higher, use backports.foobar from PyPI".

Sure, you basically can't wrong with recommending the "big players" like
Numpy, but usually they are well known anyway.  Any smaller package could
quickly become obsolete, and we're not exactly quick with updating outdated
docs (that do not deal with a specific API item) anyway -- see e.g. the HOWTO
documents.

I think that a list of "stdlib ++" should be maintained by the greater
community, after all, it is about stuff *not* prepared by the CPython team.

It may be that a better categorization of PyPI is all we need (i.e. replace
the Trove classifiers with something more prominent and more straightforward).

cheers,
Georg



More information about the Python-ideas mailing list