On Sep 18, 2014, at 8:37, Paul Moore email@example.com wrote:
On 18 September 2014 16:23, Petr Viktorin firstname.lastname@example.org wrote:
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_.
Collecting that knowledge together somewhere so that people for whom the above is *not* self-evident could easily find it, would be a worthwhile exercise.