requests.{get,post} timeout

Jon Ribbens jon+usenet at unequivocal.eu
Wed Aug 23 18:54:29 EDT 2017


On 2017-08-23, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

I don't understand - in the above paragraph you first explain how
it cannot be done without help from requests, then you state that it
can be done without help from requests. Was your first explanation
wrong?

> 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.

Yes. Which is a very common situation - indeed, I wouldn't be
surprised if it is the most common situation in which requests is
used. It is certainly the situation I was trying to use requests in
when I came up against this problem.



More information about the Python-list mailing list