Re: requests.{get,post} timeout

On 2017-08-25, Chris Angelico wrote: > On Sat, Aug 26, 2017 at 6:16 AM, Jon Ribbens > wrote: >> I said it in the majority of the posts I've made in this thread. >> I said it in the post you were responding to just now. I'm using >> threads. Now I've

Re: requests.{get,post} timeout

On Sat, Aug 26, 2017 at 6:16 AM, Jon Ribbens wrote: > On 2017-08-25, Chris Angelico wrote: >> On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens >> wrote: >>> On 2017-08-25, Chris Angelico wrote: On Sat,

Re: requests.{get,post} timeout

On 2017-08-25, Chris Angelico wrote: > On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens > wrote: >> On 2017-08-25, Chris Angelico wrote: >>> On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens >>> wrote: On

Re: requests.{get,post} timeout

On Sat, Aug 26, 2017 at 5:40 AM, Jon Ribbens wrote: > On 2017-08-25, Chris Angelico wrote: >> On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens >> wrote: >>> On 2017-08-25, Chris Angelico wrote: That

Re: requests.{get,post} timeout

On 2017-08-25, Chris Angelico wrote: > On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens > wrote: >> On 2017-08-25, Chris Angelico wrote: >>> That looks like an exception to me. Not a "process is now terminated". >>> That's what

Re: requests.{get,post} timeout

On Sat, Aug 26, 2017 at 1:47 AM, Jon Ribbens wrote: > On 2017-08-25, Chris Angelico wrote: >> That looks like an exception to me. Not a "process is now terminated". >> That's what happened when I pressed Ctrl-C (the IP address was >> deliberately

Re: requests.{get,post} timeout

On 2017-08-25, dieter wrote: > This may no longer work. Long ago, I have often been plagued > by such EINTR exceptions, and I have wished heavily that in those > cases the IO operation should be automatically resumed. In recent time, > I have no longer seen such exceptions -

Re: requests.{get,post} timeout

On 2017-08-25, Chris Angelico wrote: > That looks like an exception to me. Not a "process is now terminated". > That's what happened when I pressed Ctrl-C (the IP address was > deliberately picked as one that doesn't currently exist on my network, > so it took time). Ok yes, so

Re: requests.{get,post} timeout

Chris Angelico writes: > ... > That looks like an exception to me. Not a "process is now terminated". > That's what happened when I pressed Ctrl-C (the IP address was > deliberately picked as one that doesn't currently exist on my network, > so it took time). What Jon argues

Re: requests.{get,post} timeout

Jon Ribbens writes: > On 2017-08-24, Chris Angelico wrote: >> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens >> wrote: >>> Where did you explain how it can be done without help? As far as I'm >>> aware, you can't close the

Re: requests.{get,post} timeout

On Fri, Aug 25, 2017 at 10:42 AM, Jon Ribbens wrote: > On 2017-08-24, Chris Angelico wrote: >> Only in the sense that "kill" is the Unix term for "send signal". >> Python catches the signal, the system call terminates with EINTR, and >> the exception

Re: requests.{get,post} timeout

On 2017-08-24, Chris Angelico wrote: > On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens > wrote: >> On 2017-08-24, Chris Angelico wrote: >>> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens >>> wrote:

Re: requests.{get,post} timeout

On Thursday, August 24, 2017 at 5:02:12 PM UTC+1, Chris Angelico wrote: > > (Caveat: I have no idea how this works on Windows. I do expect, > though, that it will abort the connection without terminating the > process, just like it does on Unix.) > > ChrisA There was a big thread "cross

Re: requests.{get,post} timeout

On Fri, Aug 25, 2017 at 5:07 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote: >>> Signals are an arcane Unix communication method. I strongly recommend >>> against using signals for

Re: requests.{get,post} timeout

Chris Angelico : > On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote: >> Signals are an arcane Unix communication method. I strongly recommend >> against using signals for anything but terminating a process, and even >> then you have to be extra careful.

Re: requests.{get,post} timeout

On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens >> wrote: >>> By that, do you mean "kill the process"? That's obviously not a >>> sensible answer in

Re: requests.{get,post} timeout

Chris Angelico : > On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens > wrote: >> By that, do you mean "kill the process"? That's obviously not a >> sensible answer in general, especially given we were including >> processes which have no terminal or user

Re: requests.{get,post} timeout

On Fri, Aug 25, 2017 at 12:17 AM, Jon Ribbens wrote: > On 2017-08-24, Chris Angelico wrote: >> On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens >> wrote: >>> Where did you explain how it can be done without help? As far as I'm

Re: requests.{get,post} timeout

On 2017-08-24, Chris Angelico wrote: > On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens > wrote: >> Where did you explain how it can be done without help? As far as I'm >> aware, you can't close the socket without help since you can't get >> access to

Re: requests.{get,post} timeout

On Thu, Aug 24, 2017 at 9:43 PM, Jon Ribbens wrote: > On 2017-08-23, Chris Angelico wrote: >> On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens >> wrote: >>> On 2017-08-23, Chris Angelico wrote: Yes and

Re: requests.{get,post} timeout

On 2017-08-23, Chris Angelico wrote: > On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens > wrote: >> On 2017-08-23, Chris Angelico wrote: >>> Yes and no. If requests provided a 'cancel query' feature, it would >>> play nicely with

Re: requests.{get,post} timeout

On Thu, Aug 24, 2017 at 8:54 AM, Jon Ribbens wrote: > On 2017-08-23, Chris Angelico 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

Re: requests.{get,post} timeout

On 2017-08-23, Chris Angelico 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

Re: requests.{get,post} timeout

Chris Angelico : > What I said was that you don't need threading or alarms because most > of the time you can let the user use SIGINT. And without the (utterly > totally useless) threading that you have here, it works flawlessly: > Ctrl-C instantly breaks the recv call. Oh, if

Re: requests.{get,post} timeout

On Thu, Aug 24, 2017 at 2:59 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> 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

Re: requests.{get,post} timeout

Chris Angelico : > 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, Well, no, it doesn't. First run:

Re: requests.{get,post} timeout

On Thu, Aug 24, 2017 at 12:52 AM, Jon Ribbens 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

Re: requests.{get,post} timeout

On 2017-08-23, Chris Angelico wrote: > On Wed, Aug 23, 2017 at 10:52 PM, Jon Ribbens > wrote: >> Yes, what I was interested to learn was how the monitoring thread can >> "cut off" the requesting thread. > > Ah, I see. That partly depends on your

Re: requests.{get,post} timeout

Jon Ribbens : > Yes, what I was interested to learn was how the monitoring thread can > "cut off" the requesting thread. In general, that cannot be done. Often, you resort to a dirty trick whereby the monitoring thread closes the I/O object requesting thread is waiting

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 10:52 PM, Jon Ribbens wrote: > On 2017-08-23, Chris Angelico wrote: >> On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens >> wrote: >>> I am interested to learn what you mean by "with a thread". How would

Re: requests.{get,post} timeout

On 2017-08-23, Chris Angelico wrote: > On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens > wrote: >> I am interested to learn what you mean by "with a thread". How would >> one execute a requests, er, request in a thread with a proper timeout? > >

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 9:10 PM, Jon Ribbens wrote: > On 2017-08-22, Chris Angelico wrote: >> On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens >> wrote: >>> I have no idea what you mean here. The only sane way to implement the

Re: requests.{get,post} timeout

On 2017-08-22, Chris Angelico wrote: > On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens > wrote: >> I have no idea what you mean here. The only sane way to implement the >> request timeout is to provide both types of timeout. > > You could provide both,

Re: requests.{get,post} timeout

Skip Montanaro writes: > ... > Given the semantics of timeouts which percolate up from the socket > level, I agree with Chris. It has a particular meaning, that > implemented by the underlying socket layer. Unfortunately, the word > "timeout" can take on related (but

Re: requests.{get,post} timeout

> You could provide both, but since one of them can be handled > externally (with a thread, with a SIGALRM, or with some other sort of > time limiting), the other one MUST be provided by the request. Given the semantics of timeouts which percolate up from the socket level, I agree with Chris. It

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 5:06 AM, Jon Ribbens wrote: >> You can always add in the overall timeout separately. If the low-level >> timeout were implemented that way, there would be no way to externally >> add the other form of timeout. Therefore the only sane way to >>

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 5:10 AM, MRAB wrote: > On 2017-08-22 19:43, Chris Angelico wrote: >> >> On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens >> wrote: >>> >>> On 2017-08-22, Chris Angelico wrote: On Wed, Aug 23,

Re: requests.{get,post} timeout

On 2017-08-22, Chris Angelico wrote: > The low-level timeout will distinguish between those. If you want a > high-level timeout across the entire job, you can do that too, but > then you have to figure out exactly how long is "too long". Let's say > you set a thirty-second

Re: requests.{get,post} timeout

On 2017-08-22 19:43, Chris Angelico wrote: On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens wrote: On 2017-08-22, Chris Angelico wrote: On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens wrote: Yes. There is no timeout feature

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 4:31 AM, Grant Edwards wrote: > On 2017-08-22, Chris Angelico wrote: > >> """ >> Once your client has connected to the server and sent the HTTP >> request, the read timeout is the number of seconds the client will >> wait for

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 4:14 AM, Jon Ribbens wrote: > On 2017-08-22, Chris Angelico wrote: >> On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens >> wrote: >>> Yes. There is no timeout feature that can be used to limit the total

Re: requests.{get,post} timeout

On 2017-08-22, Chris Angelico wrote: > """ > Once your client has connected to the server and sent the HTTP > request, the read timeout is the number of seconds the client will > wait for the server to send a response. (Specifically, it's the number > of seconds that the client

Re: requests.{get,post} timeout

On 2017-08-22, Chris Angelico wrote: > On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens > wrote: >> Yes. There is no timeout feature that can be used to limit the total >> time a 'requests' request takes. Some people might think that this is >> a serious

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 2:58 AM, Jon Ribbens wrote: > On 2017-08-22, Skip Montanaro wrote: >> I'm using the requests module with timeouts to fetch URLs, for example: >> >> response = requests.get("http://www.google.com/;, timeout=10) >> >>

Re: requests.{get,post} timeout

> """ > Once your client has connected to the server and sent the HTTP > request, the read timeout is the number of seconds the client will > wait for the server to send a response. (Specifically, it's the number > of seconds that the client will wait between bytes sent from the > server. In 99.9%

Re: requests.{get,post} timeout

On 2017-08-22, Skip Montanaro wrote: > I'm using the requests module with timeouts to fetch URLs, for example: > > response = requests.get("http://www.google.com/;, timeout=10) > > I understand the timeout value in this case applies both to creating the > connection

Re: requests.{get,post} timeout

On Wed, Aug 23, 2017 at 12:02 AM, Skip Montanaro wrote: > I'm using the requests module with timeouts to fetch URLs, for example: > > response = requests.get("http://www.google.com/;, timeout=10) > > I understand the timeout value in this case applies both to

requests.{get,post} timeout

I'm using the requests module with timeouts to fetch URLs, for example: response = requests.get("http://www.google.com/;, timeout=10) I understand the timeout value in this case applies both to creating the connection and fetching the remote content. Can the server dribble out the content