> On 09/12/2020 11:28 AM nhpython wrote:
>
>
> Windows 10 x64 Pro v10.0.19041.488 build 19041
> 2020-09 Cumulative Update for Win 10 Ver 2004 for x64 KB4571756
> 2020-09 Cumulative Update for .NET Framework 3.5 & 4.8 for Win 10 Ver 2004
> for x64 KB4576478
> requests-html 0.10.0
> pyppeteer
On 04/04/2019 12:57, Jack Dangler wrote:
Hi, all. Just getting started but already have an idea for something to
save me some grief
we have lists of files that reside on a sharepoint site at work that we
pick from. These have a variety of data items in them and we need to
start the process by
>> Or maybe I misunderstood the docs and the timeout means the max. time
>> elapsed between receiving two chunks of data from the server?
> Yes. It's documented better here:
> http://docs.python-requests.org/en/master/user/advanced/#timeouts
>
> You can't specify a "total time" within which the op
On 2018-01-15, Nagy László Zsolt wrote:
>> In other words: if the server starts to send the response, but then
>> stops sending it (without closing the connection), then this will block
>> forever anyway.
> Or maybe I misunderstood the docs and the timeout means the max. time
> elapsed between rec
> In other words: if the server starts to send the response, but then
> stops sending it (without closing the connection), then this will block
> forever anyway.
Or maybe I misunderstood the docs and the timeout means the max. time
elapsed between receiving two chunks of data from the server?
--
> (a) are you setting daemon=True on the thread?
> (b) are you setting a timeout on the requests call?
Hmm setting the timeout might not be the solution. This is from the docs
of the requests module:
>
> Note
>
> |timeout| is not a time limit on the entire response download; rather,
> an exception
2018. 01. 13. 15:03 keltezéssel, Jon Ribbens írta:
> On 2018-01-13, Nagy László Zsolt wrote:
>> I have a multi threaded Windows service written in Python. It is running
>> on 3.6.2. Sometimes I cannot stop the service, because on of the
>> threads won't exit. I have narrowed down the problem to
On 2018-01-13, Nagy László Zsolt wrote:
> I have a multi threaded Windows service written in Python. It is running
> on 3.6.2. Sometimes I cannot stop the service, because on of the
> threads won't exit. I have narrowed down the problem to request and
> _lib.SSL_read.
(a) are you setting daemon=
On 13/01/18 11:34, Nagy László Zsolt wrote:
> Hi!
>
> I have a multi threaded Windows service written in Python. It is running
> on 3.6.2. Sometimes I cannot stop the service, because on of the
> threads won't exit. I have narrowed down the problem to request and
> _lib.SSL_read. I have used a mo
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 said it again.
>
> You said WHY you are using
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, Aug 26, 2017 at 1:47 AM, Jon Ribbens
wrote:
> On 2017-08-25, Chris Angelico wro
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 2017-08-25, Chris Angelico wrote:
> That looks like an exception to me. Not a "process
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 looks like an exception to me. Not a "process is now terminated".
That's what happened wh
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 happened when I pressed Ctrl-C (the IP address was
>>> deliberately pic
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 picked as one that doesn't currently exist on my n
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 - and I concluded that m
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 ctrl-C is sending
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 about: signals are de
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 socket without help since you can't get
>>> access to it, and as you ment
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 is raised. Give it a try.
>
> Give what a try?
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:
Where did you explain how it can be done without help? As far as I'm
aware, you can't clo
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 platform
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 anything but terminating a process, and even
>>> then you h
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.
>>
>> I have seen code that uses signa
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 general, especially given we were including
>>> processes which have no
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 sitting there watching them.
>
> Only in the s
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
>>> aware, you can't close the socket without help since you can't get
>
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 it, and as you mentioned even if you were to do
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 no. If requests provided a 'cancel query' feature, it would
play nicely with everythin
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 everything else, but (a) the entire concept here is
>>> that the requ
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 request has stalled, so you COULD just ignore the p
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 without actually ca
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 you give up threadi
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 aborts a socket read,
>
> Well, no, i
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:
==
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 cancel the request yourself
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 definition of "cut off", and
> how it needs to int
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 on, triggering an immediate
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
>>> one execute a requests, er, request in a thread with a proper timeou
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?
>
> Assuming that by "proper timeout" you mean "limit the
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
>>> request timeout is to provide both types of timeout.
>>
>> You could
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, but since one of them can be handled
> externa
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 different) meanings, depending
> 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 h
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
>> implement the request 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, 2017 at 2:58 AM, Jon Ribbens
wrote:
>
> Yes. There is no tim
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 timeout. Great! Now some
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 that can be used to limit the total
time a 'requests' request takes. Some
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 the server to send a response. (Specifically, i
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
>>> time a 'requests' request takes. Some people might think that this is
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 will wait between
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 flaw in the requests library that would need
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)
>>
>> I understand the timeout value in this case applies
> """
> 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%
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 and fetching the remote co
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 creating the
> connection and fet
Thanks for your help, I realise that what I wanted was chromes default new
tab page, not a blank page. 'about:blank' worked fine but it wasn't what I
wanted sorry. I'll try the CTRL+4 later and see it that works.
On 14 Sep 2016 21:11, "John Gordon" wrote:
> In Jamie <
> ja9...@my.bristol.ac.uk>
In Jamie
writes:
> I am not sure if this is an intended consequence but when using the
> webbrowser module to open a new blank browser tab in chrome it opens it
> in a new browser window instead of using the current window. Providing
There is an internal setting within Chrome that controls
On 2016-09-14 17:53, Jamie wrote:
Hi,
I am not sure if this is an intended consequence but when using the
webbrowser module to open a new blank browser tab in chrome it opens it
in a new browser window instead of using the current window. Providing
any complete url provides different behaviour,
59 matches
Mail list logo