Nick, I see. The Python C interface provides a very simple way of raising an exception in the case where the exception is only passed one argument, the error message. It even makes it easy to interpolate arguments into that error message. If it is important to include other arguments, as with OSError, one would presumably use another mechanism that requires more effort. Your suggestion of providing an alternative to PyErr_Format() that squirreled away its arguments into the exception and deferred their interpolation into the error message seems like a very nice approach. But as you say, it does not seem trivial to implement in C. If it could be extended to support named arguments, it does have the benefit that it could unify the way exceptions are raise from C. The alternative would be to simply enhance the individual exceptions on an as needed basis as you suggested earlier. That could be easy if the exceptions are only raised in one or two places. Do you have a sense for how many places raise some of these common exceptions such as NameError, KeyError, etc.? -Ken On Sun, Jul 16, 2017 at 02:18:40PM +1000, Nick Coghlan wrote:
On 16 July 2017 at 10:12, Jeff Walker <jeff.walker00@yandex.com> wrote:
Sorry Stephen (and Steven). I'll do better next time.
The way I see it there are two problems, and the second causes the first.
The first problem is that there is no direct access to the components that make up the error in some of the standard Python exceptions.
>>> foo Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'foo' is not defined
If you need access to the name, you must de-construct the error message. To get direct access to the name, it would need to be passed to the exception when raised. Why wasn't that done?
Ease of implementation mainly, as PyErr_Format is currently the simplest general purpose mechanism for raising informative exceptions from the C code: https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Format
All the more structured ones currently require expanding the C API to cover creating particular exception types with particular field values (the various PyErr_Set* functions listed on that page).
That does prompt a thought, though: what if there was an f-string style "PyErr_SetStructured" API, where instead of writing 'PyErr_Format(PyExc_NameError, "name '%.200s' is not defined", name);', you could instead write 'PyErr_SetStructured(PyExc_NameError, "name '{name:.200s}' is not defined", name);', and that effectively translated to setting a NameError exception with that message *and* setting its "name" attribute appropriately.
The key benefit such a switch to f-string style formatting would provide is the ability to optionally *name* the fields in the exception message if they correspond to an instance attribute on the exception being raised.
Actually implementing such an API wouldn't be easy by any means (and I'm not volunteering to do it myself), but it *would* address the main practical barrier to making structured exceptions more pervasive in the reference interpreter.
Cheers, Nick.