[Python-ideas] notify exception during raise (once magic properties are set)

[Travis Everett]

Thanks for the addendum--I suspected a mix of performance and the
difficulty of handling potential failures at that point would be the
ultimate answer to why the exception is already cut out of the loop there.
Not that the dumber __raised__() version wouldn't have the same problem,
but its behavior in case of failure could be straightforward.

An idea I had last night led to some progress this morning. BaseException's
with_traceback(tb) method already sets some thematic precedent for users
being able to cause new exceptions while setting values within the raise
process, (though unfortunately it looks like the traceback it sets gets
overwritten by the new one set in C during the raise.) I realize that this
is just a thematic precedent, since they'd be caused at very different
places.

For now I've replaced my previous workaround with a with_cause(c) method
which is at least a step in the right direction for handling my specific
case in a way that feels roughly congruent with existing idioms, makes
sense in that context, and cleans up code using the exceptions; __cause__
still gets overwritten by the C code, but this doesn't cause trouble since
we know what this object will be at raise time. This wouldn't suffice if I
needed access to __traceback__ at this point.

RE the question in your first response on patch benchmarking: I'm new to
the list and have no previous contributions, but there's a first time for
everything; if the information on doing so is readily available I should be
fine, but otherwise I'd need some direction.

On Fri, Apr 10, 2015 at 5:07 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Apr 10, 2015, at 14:39, Andrew Barnert <
> abarnert at yahoo.com.dmarc.invalid> wrote:
>
> On Apr 10, 2015, at 12:54, Travis Everett <travis.a.everett at gmail.com>
> wrote:
>
> Hi all,
>
> I have a specialized use case for exceptions which need to analyze their
> __cause__ property before they're fully initialized. The property isn't set
> until after init, and (forgive my ignorance of Python's source!) appears to
> be done at the C level in a way that it can't be observed with a property
> setter or __setattr__. I currently create a method to do this post-init
> work as a workaround, and push the burden of making sure it gets called on
> the code using the exceptions--but this makes the exceptions idiomatic and
> error-prone.
>
> A magic method called once all of the special exception properties are
> already set would suffice. The exception could define something like
> __raised__(self) to react to the new values of those properties.
>
> A more comprehensive approach might be a __raise__(self, cause, context,
> traceback...) method which has full control over setting the properties,
> but I assume there are good reasons why the usual channels (setters and
> __setattr__) are cut out of the loop.
>
>
> I'd assume the only reasons are to make the code a bit simpler and a bit
> more efficient.
>
>
> Actually, on second though, it's not _quite_ that simple.
>
> First, settings args, __traceback__ etc. are no longer hookable; it seems
> like you'd want those to be as well, for consistency? So that's a few more
> functions to change.
>
> Second, the API functions for setting cause and context (and the private
> API function for automatically setting context) can't possibly fail
> anywhere, so they have no return value. Changing them to go through SetAttr
> means they now can (your __setattr__ could raise anything it wants--or even
> creating the 1 object to store in __suppress_context__ could fail). Should
> we just swallow and ignore any such exceptions when called from the C error
> API? (C code that uses the exception type API or the object API will of
> course continue to get exceptions, as will Python code, it's just the error
> machinery that would ignore errors from munging exceptions to be raised.)
>
> Adding some new __raise__ or __raised__ special-purpose protocol doesn't
> seem like it would be any simpler or more efficient than just changing the
> existing APIs to access the attributes via SetAttr, which would give you
> what you want without being a special case.
>
> Also notice that there's an open PEP (
> https://www.python.org/dev/peps/pep-0490/) to make the C API for raising
> exceptions automatically set the context instead of forcing it to be done
> manually (with a private API function), as a few builtin and stdlib
> functions do. So it seems safer to change things in a way that would work
> equally well with the current APIs, with that change, and with all
> reasonable alternatives to that change--and again, using SetAttr seems like
> the simplest way to make sure of that.
>
> But either way, it's a relatively local and simple change in
> Objects/exceptions.c.
>
> I suspect the big thing you'd need to get this accepted is to show that
> the performance cost is negligible. Do you know how to run appropriate
> benchmarks and present the results if someone else writes the patch?
>
> I was encouraged to bring discussion here (to see if there's any
> traction) after opening an enhancement request (
> http://bugs.python.org/issue23902).
>
>
>
> Cheers,
> Travis
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150411/a2e59765/attachment-0001.html>