Oops, it was pointed out to me that this message isn't super clear.
To put it more simply:
Please go ahead and do this, using the loop API everywhere would be a lot
better for my uses :-).
-glyph
On Feb 10, 2014, at 5:12 PM, Glyph gl...@twistedmatrix.com wrote:
I have a use-case, which is
On 2/6/2014, 11:02 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanovyselivanov...@gmail.comwrote:
A question to you and Guido: should the callback receive
three arguments: loop, exception, and context, where
context is a namedtuple (so we can add new fields to it
in
Can't you add a reference to the loop to the tb logger object? The loop
should outlive any futures anyway (since the future has a reference to the
loop) and it shouldn't be a ref cycle.
On Fri, Feb 7, 2014 at 11:17 AM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2/6/2014, 11:02 PM, Guido
On 2/7/2014, 3:52 PM, Guido van Rossum wrote:
Can't you add a reference to the loop to the tb logger object? The loop
should outlive any futures anyway (since the future has a reference to the
loop) and it shouldn't be a ref cycle.
Sure.
Another question: logger.exception is also used in:
-
On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2/7/2014, 3:52 PM, Guido van Rossum wrote:
Can't you add a reference to the loop to the tb logger object? The loop
should outlive any futures anyway (since the future has a reference to the
loop) and it
On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
And one more, aesthetic question: the currently agreed on signature of
exception handlers is '(loop, context)'. I have a method
BaseEventLoop.default_exception_handler(self, context), but when the
method is bound, its signature is just '(context)',
OK, don't change it. :-)
On Fri, Feb 7, 2014 at 1:53 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
And one more, aesthetic question: the currently agreed on signature of
exception handlers is '(loop, context)'. I have a method
On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanovyselivanov...@gmail.comwrote:
On 2/7/2014, 3:52 PM, Guido van Rossum wrote:
Can't you add a reference to the loop to the tb logger object? The loop
should outlive any futures anyway (since the future
OK, go for it unless Glyph pipes up. :-)
On Fri, Feb 7, 2014 at 2:03 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanovyselivanov...@gmail.com
wrote:
On 2/7/2014, 3:52 PM, Guido van Rossum wrote:
As discussed with Guido in issue #80
(https://code.google.com/p/tulip/issues/detail?id=80),
I'm proposing a strawman design for having a user definable event loop
handler for unhandled exceptions.
Two new API points:
- loop.set_exception_handler(callback)
Sets 'callback' as a new
On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov yselivanov...@gmail.comwrote:
As discussed with Guido in issue #80
(https://code.google.com/p/tulip/issues/detail?id=80),
I'm proposing a strawman design for having a user definable event loop
handler for unhandled exceptions.
Two new API
On 2/6/2014, 1:24 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov yselivanov...@gmail.comwrote:
As discussed with Guido in issue #80
(https://code.google.com/p/tulip/issues/detail?id=80),
I'm proposing a strawman design for having a user definable event loop
handler
On Thu, Feb 6, 2014 at 12:09 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2/6/2014, 1:24 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
As discussed with Guido in issue #80
On 2/6/2014, 3:44 PM, Guido van Rossum wrote:
[snip]
I'm not sure. The default exception handler may, over time, develop
some useful custom behavior, and it's not like its signature is very
complicated or using it is fraught with problems. So I don't see much
downside to letting users call
Hi,
2014-02-06 17:53 GMT+01:00 Yury Selivanov yselivanov...@gmail.com:
I'm proposing a strawman design for having a user definable event loop
handler for unhandled exceptions.
With my short experience of asyncio, I can say that it's a pain to
reconnect an unhandled exception to the future and
However, I'm not sure how passing the future/handle to the
handler may help. You have the name of the failed callback
in the traceback of the exception. And, in many places all
you have is just the failed callback function, and no
related future or task.
I'm talking about Future destructor
On 2/6/2014, 5:34 PM, Victor Stinner wrote:
Install an handler for unhandled exceptions is not something new: there is
already sys.displayhook and sys.excepthook.
I'm not sure that it's useful to get the default handler. Just give
access to the current handler. So when you setup a new handler,
On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanov yselivanov...@gmail.comwrote:
A question to you and Guido: should the callback receive
three arguments: loop, exception, and context, where
context is a namedtuple (so we can add new fields to it
in future releases). For now, 'context' can have
18 matches
Mail list logo
