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