On Thu, Sep 18, 2014 at 11:10 AM, Andrew Barnert
On Sep 18, 2014, at 8:37, Paul Moore
On 18 September 2014 16:23, Petr Viktorin
Listing "stdlib++" projects would mean vouching for them, even if only implicitly. Indeed, let's not get too carried away.
Nevertheless, there is community knowledge "out there" on what constitute best of breed packages. For example "everyone knows" that requests is the thing to use if you want to issue web requests.
Except in those cases that requests actually makes harder, like trying to send files over SOAP+MIME. Or when you can most easily explain what you want in terms of libcurl code or a curl command line.
But as Terry pointed out earlier in the thread, one advantage of the "stdlib++" idea is that you don't have to pick one, you can pick one or more. If the urllib.request docs said that requests makes easy cases, and even many pretty complex ones, easy; urllib3 provides as much flexibility as possible in a stdlib-like interface for those rare cases that requests can't make easy; pycurl makes it easier to translate web requests from C programs or shell scripts; etc., then there's no problem.
And equally, requests is "clearly" well-maintained and something you can rely on.
If Kenneth got hit by a bus, requests would be in more trouble than something in the stdlib would if Guido, or the module's maintainer, did. The risk isn't _high_--it's certainly never deterred me from using it, or even convincing managers in corporate settings that we should use it--but that doesn't mean it's not _higher than the stdlib_.
Seeing as Kenneth has two core-developers working on it, one of whom works on it as part of their contributions to OpenStack, I think your estimation of the bus number is too low. Granted either Cory or I need the ability to push to PyPI, but I think Richard and Donald know Cory and I well enough to trust us to maintain the package as we currently do.