On Thu, Aug 24, 2017 at 12:52 AM, Jon Ribbens <jon+use...@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 -- https://mail.python.org/mailman/listinfo/python-list
