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

Andrew Barnert abarnert at yahoo.com
Thu Sep 18 18:10:40 CEST 2014


On Sep 18, 2014, at 8:37, Paul Moore <p.f.moore at gmail.com> wrote:

> On 18 September 2014 16:23, Petr Viktorin <encukou at gmail.com> 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.

Agreed.


More information about the Python-ideas mailing list