requests.{get,post} timeout

[Chris Angelico]

On Thu, Aug 24, 2017 at 12:52 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
> OK cool, so circling back to where you were - which is the same place
> that the 'requests' developers are - which is the claim that requests
> does not need to provide an "overall timeout" feature because you
> can cancel the request yourself is untrue since, as you explain above,
> you cannot in fact cancel the request yourself without some sort of
> support for this in the module itself. Sure, requests *could* provide
> a "cancel" feature, just the same as it *could* provide an "overall
> timeout" feature, but it doesn't actually provide either, and this
> is a problem.

Yes and no. If requests provided a 'cancel query' feature, it would
play nicely with everything else, but (a) the entire concept here is
that the request has stalled, so you COULD just ignore the pending
query and pretend it's failed without actually cancelling it; and (b)
you could just close the underlying socket without help, but it might
mess up future queries that end up getting put onto the same socket.
It's not that you CAN'T do this without help (which is the case for a
"time between bytes" timeout), but that having help would allow
requests *itself* to benefit.

But also, this honestly isn't as big an issue as you might think. If
the user thinks a program has been running for too long, s/he can hit
Ctrl-C. Voila! Signal is sent, which aborts a socket read, and thus
the request. And if your top-level code is doing something else (so
cancelling one request shouldn't terminate the whole program), Python
already lets you catch KeyboardInterrupt. This is ONLY a problem when
you need to have a program decide *by itself* that a request has taken
too long.

ChrisA