On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum wrote:
>
>> It's 11 days. Which is pretty reasonable server uptime.
>>
>
> Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly
> thought I could do better than the OP.
>
A helpful trivia: a year is approximately π times 10 million
On 18.12.2015 22:09, Guido van Rossum wrote:
I guess we could make the default arg to sleep() 1e9. Or make it None
and special-case it. I don't feel strongly about this -- I'm not sure
how baffling it would be to accidentally leave out the delay and find
your code sleeps forever rather than rai
Using an Event is slightly better because you just wait for it -- you don't
have to catch an exception. It's just not one of the better-known parts of
asyncio.
On Fri, Dec 18, 2015 at 1:42 PM, Andrew Barnert wrote:
> On Friday, December 18, 2015 1:09 PM, Guido van Rossum
> wrote:
>
>
> >I guess
On Friday, December 18, 2015 1:09 PM, Guido van Rossum wrote:
>I guess we could make the default arg to sleep() 1e9. Or make it None and
>special-case it. I don't feel strongly about this -- I'm not sure how baffling
>it would be to accidentally leave out the delay and find your code sleeps
>
> I guess we could make the default arg to sleep() 1e9. Or make it None and
> special-case it.
By writing the OP, I considered suggesting this approach and rejected. I would
have suggest the using Ellipsis (`...`) for the special case which seemed to
explain more what is done plus it can hardly
> Maybe you can help by submitting a patch that prevents this error! Are you
> interested?
I'd be honored.
Ádám
(http://szieberthadam.github.io/)
P.S.: Was thinking about a longer answer but finally I ended up with this one :)
___
Python-Dev mailing li
Thanks for your reply Andrew!
> Personally I don't feel the need for `wait_forever()` or
> `loop.creae_context_task()`.
>
> But even if you need it you may create it from scratch easy, isn't it?
Indeed. I was prepared for such opinions which is OK. It is better to think it
through several times
On Fri, Dec 18, 2015 at 12:45 PM, Andrew Barnert wrote:
> On Dec 18, 2015, at 10:36, Guido van Rossum wrote:
>
> On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám
> wrote:
>
>> Thanks for your reply Guido!
>>
>> > - In theory, instead of waiting for a Future that is cancelled by a
>> > handler,
On Dec 18, 2015, at 10:36, Guido van Rossum wrote:
>
>> On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám wrote:
>> Thanks for your reply Guido!
>>
>> > - In theory, instead of waiting for a Future that is cancelled by a
>> > handler, you should be able to use asyncio.sleep() with a very large n
On Dec 18, 2015, at 10:25, Szieberth Ádám wrote:
>
>> - In theory, instead of waiting for a Future that is cancelled by a
>> handler, you should be able to use asyncio.sleep() with a very large number
>> (e.g. a million seconds).
>
> I was thinking on this too but it seemed less explicit to me t
No, it just means Windows users should not try to catch signals on Windows.
Signals don't really exist there, and the simulation supporting only a few
signals is awful (last I tried ^C was only processed when the process was
waiting for input from stdin, and I had to use the BREAK key to stop
runa
On 12/18/2015 10:36 AM, Guido van Rossum wrote:
I was opted to the signal module because `signal` documentation
suggest that
it alos supports Windows while asyncio documentation states that
`loop.
add_signal_handler()` is UNIX only.
Unfortunately that's true, but using the
On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám
wrote:
> Thanks for your reply Guido!
>
> > - Instead of calling signal.signal() yourself, you should use
> > loop.add_signal_handler(). It makes sure your signal handler doesn't run
> > while another handler is already running.
>
> I was opted to
Thanks for your reply Guido!
> - Instead of calling signal.signal() yourself, you should use
> loop.add_signal_handler(). It makes sure your signal handler doesn't run
> while another handler is already running.
I was opted to the signal module because `signal` documentation suggest that
it alos
On Fri, 18 Dec 2015 18:29:35 +0200, Andrew Svetlov
wrote:
> I my asyncio code typical initialization/finalization procedures are
> much more complicated.
> I doubt if common code can be extracted into asyncio.
> Personally I don't feel the need for `wait_forever()` or
> `loop.creae_context_task()
I agree with Andrew that there are too many different scenarios and
requirements to make this a useful library function. Some notes on the
actual code you posted:
- Instead of calling signal.signal() yourself, you should use
loop.add_signal_handler(). It makes sure your signal handler doesn't run
I my asyncio code typical initialization/finalization procedures are
much more complicated.
I doubt if common code can be extracted into asyncio.
Personally I don't feel the need for `wait_forever()` or
`loop.creae_context_task()`.
But even if you need it you may create it from scratch easy, isn't
Hi Developers!
This is my first post. Please excuse me my poor English. If anyone is
interested, I wrote a small introduction on my homepage. Link is at the bottom.
This post is about how to effectively implement the new asynchronous context
manager in a typical network server.
I would appreciat
18 matches
Mail list logo
