On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka <storch...@gmail.com> 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 second object would totally makes sense.
If you have plans for adding new details in future, I propose to add a
6th parameter "context" or "extra" (always None currently). It is as
extensible as packing all arguments into a single structure, but you do
not need to introduce the structure type and create its instance until
you need to pass additional info.
In my implementation, UnraisableHookArgs is a C "structseq" type. In
short, it's a tuple. make_unraisable_hook_args() basically builds a
tuple of 4 items and uses PyTuple_SET_ITEM() to set the items.
_PyErr_WriteUnraisableDefaultHook() uses PyStructSequence_GET_ITEM()
to get items.
The code pack and unpack UnraisableHookArgs is simple and reliable.
An "unraisable exception" doesn't mean that Python is collapsing. It
only means that the code is unable to report the exception to the
caller: there is no reason why allocating a 4-tuple or calling a
simple Python function (sys.unraisablehook) would fail.
--
I dislike the compromise of having an API in 2 parts: positional
parameters for some parameters, and a structure for some other
parameters. I prefer to pack all arguments into a single structure.
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?
I'm not even convinced we need the obj argument, or that it's a good
idea - this is yet another place where it's likely to be dead/dying
already. And what can you do with it? Resurrection seems like a really
bad idea, as does diving into a custom __repr__. There's no useful
recovery mechanism here that I'm aware of, so I'd be in favor of just
passing through the exception and nothing else.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
