On Thu, May 16, 2019 at 1:23 PM Victor Stinner wrote:
>
> Le jeu. 16 mai 2019 à 20:58, Petr Viktorin a écrit :
> > I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> > holdover from older Python versions, and all the information is now in
> > the exception instance.
> > Is
Le ven. 17 mai 2019 à 03:10, Gregory P. Smith a écrit :
> I like the feature, we should have it. It'll be useful for debugging and
> probably more.
>
> Which brings me to the annoying paint color question: These exceptions were
> most definitely raised. Thus the term "unraisable" is wrong. I
I like the feature, we should have it. It'll be useful for debugging and
probably more.
Which brings me to the annoying paint color question: These exceptions were
most definitely raised. Thus the term "unraisable" is wrong. I believe you
really mean "uncatchable".
-gps
On Thu, May 16, 2019 at
On 16May2019 1441, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit :
You go on to say "pass an error message" and "keep repr(obj) if you
want", but how is this different from creating an exception that
contains the custom message, the repr of the object, and chains the
Le jeu. 16 mai 2019 à 23:46, Nathaniel Smith a écrit :
> A clever hook might want the actual object, so it can pretty-print it,
> or open an interactive debugger and let it you examine it, or
> something. Morally this is similar to calling repr(obj), but it
> doesn't literally call repr(obj).
On Thu, May 16, 2019 at 2:17 PM Steve Dower wrote:
> You go on to say "pass an error message" and "keep repr(obj) if you
> want", but how is this different from creating an exception that
> contains the custom message, the repr of the object, and chains the
> exception that triggered it?
A
Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit :
> You go on to say "pass an error message" and "keep repr(obj) if you
> want", but how is this different from creating an exception that
> contains the custom message, the repr of the object, and chains the
> exception that triggered it?
Well,
On 16May2019 1404, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit :
I really like this API, and I agree with Victor that we don't really
need more than the exception info. For future expansion, we can pass in
a different exception, no?
Sorry, I don't understand. I
Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit :
> I really like this API, and I agree with Victor that we don't really
> need more than the exception info. For future expansion, we can pass in
> a different exception, no?
Sorry, I don't understand. I explained that we need more than
Le jeu. 16 mai 2019 à 20:58, Petr Viktorin a écrit :
> I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> holdover from older Python versions, and all the information is now in
> the exception instance.
> Is the triple ever different from (type(exc), exc, exc.__traceback__)?
On Thu, May 16, 2019, 09:07 Steve Dower wrote:
>
> Actually, if the default implementation prints the exception message,
> how is this different from sys.excepthook? Specifically, from the point
> of customizing the hooks.
>
sys.excepthook means the program has fully unwound and is about to
On 5/16/19 3:23 AM, Victor Stinner wrote:
[...]
I modified my API to create an object to pack arguments. The new API
becomes sys.unraisablehook(unraisable) where unraisable has 4 fields:
exc_type, exc_value, exc_tb, obj.
[...]
I always thought the classic (exc_type, exc_value, exc_tb) triple is
> While I’m fine with the API you propose, you could consider keyword-only
arguments to help future proof the call signature. I don’t like it as much
because it’s not as backward compatibility proof, but it’s an option to
perhaps consider.
Let's say that we have: hook(*, exc_type, exc_value,
On May 16, 2019, at 03:12, Victor Stinner wrote:
> I came to the UnraisableHookArgs structseq idea because of my bad
> experience with extension warnings "hooks". Let me tell you this story
> :-)
Thanks for that!
> def showwarning(message, category, filename, lineno, file=None, line=None):
>
On 16May2019 0902, Steve Dower wrote:
Actually, if the default implementation prints the exception message,
how is this different from sys.excepthook? Specifically, from the point
of customizing the hooks.
If I were going to replace unraisablehook to do something on specific
exceptions, I'm
On 16May2019 0856, Steve Dower wrote:
On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a
écrit :
For unraisable hook, it's not hard to imagine other useful parameters
that can be passed to the hook to provide more context about the
exception. For example,
On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit :
For unraisable hook, it's not hard to imagine other useful parameters
that can be passed to the hook to provide more context about the
exception. For example, right now we only pass one object. But
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit :
> > For unraisable hook, it's not hard to imagine other useful parameters
> > that can be passed to the hook to provide more context about the
> > exception. For example, right now we only pass one object. But there
> > are cases where a
16.05.19 13:12, Victor Stinner пише:
I came to the UnraisableHookArgs structseq idea because of my bad
experience with extension warnings "hooks". Let me tell you this story
:-)
I know this story, because I followed these issues.
For unraisable hook, it's not hard to imagine other useful
After the detailed explanation, UnraisableHookArgs makes sense.
Forward-compatibility is important thing
On Thu, May 16, 2019 at 1:12 PM Victor Stinner wrote:
>
> Le jeu. 16 mai 2019 à 08:39, Serhiy Storchaka a écrit :
> >
> > 16.05.19 04:23, Victor Stinner пише:
> > > The first implementation
Le jeu. 16 mai 2019 à 08:39, Serhiy Storchaka a écrit :
>
> 16.05.19 04:23, Victor Stinner пише:
> > The first implementation of my API used sys.unraisablehook(exc_type,
> > exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
> > to add a new error message field which breaks
Le jeu. 16 mai 2019 à 04:44, Nathaniel Smith a écrit :
> What happens if the hook raises an exception?
Aha, thanks for asking the question!
If there is a custom hook and the hook fails, the default hook logs
the exception of the custom hook.
Technically, even if the default hook fails, the
16.05.19 04:23, Victor Stinner пише:
The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.
I modified my API to create an
On Wed, May 15, 2019 at 6:25 PM Victor Stinner wrote:
> I proposed a different approach: add a new sys.unraisablehook hook
> which is called to handle an "unraisable exception". To handle them
> differently, replace the hook. For example, I wrote a custom hook to
> log these exceptions into a
Hi,
I recently modified Python 3.8 to start logging I/O error in io
destructors when using the development mode (-X dev) or when Python is
built in debug mode. This change allows to debug bpo-18748 very
strange crash in PyThread_exit_thread(), when a thread closes an
arbitrary file descriptor by
25 matches
Mail list logo
