This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add PyArg_Parse format unit like O& but providing context
Type: enhancement Stage: needs patch
Components: Interpreter Core Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: larry Nosy List: georg.brandl, iritkatriel, larry, loewis, serhiy.storchaka
Priority: normal Keywords:

Created on 2012-05-07 09:35 by larry, last changed 2022-04-11 14:57 by admin.

Messages (3)
msg160125 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-05-07 09:35
If you write a PyArg_Parse "converter", and your conversion hits an error, you must raise an exception and error out.  But, since your converter has no context about the parameter, it can't provide any helpful information in the error.

For example, PyUnicode_FSConverter attempts to convert a PyUnicode object to a PyBytes object; if it gets back some other kind of object, it calls
     PyErr_SetString(PyExc_TypeError, "encoder failed to return bytes");
What parameter did this happen with?  When calling what function?  The hapless programmer is forced to guess.

In practice, the argument parser generally knows the name of the function and the name of the parameter.  It'd be nice to encode those values in the error.  But that information isn't passed in to the converter.

I propose adding a new format unit, let's call it 'O%', which is identical to 'O&' except for the signature of the converter function:

    int converter(PyObject *o, void *p, PyConverterContext_t *context);

where PyConverterContext_t is defined as

    typedef struct {
        char *function_name;
        char *parameter_name;
    } PyConverterContext_t;

If the function name or parameter name is not known, it will be NULL.
msg160128 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-05-07 10:00
It would be better if the functions PyArg_Parse* were wrapped converter's exception, in other exception with adding the names of function and parameter in the message. This will save us from necessity of the introduction of the new interface and immediately give effect to the old code.
msg397861 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-07-20 08:13
Now we have exception chaining, so Serhiy's pattern is even simpler to implement than with exception wrappers.
History
Date User Action Args
2022-04-11 14:57:29adminsetgithub: 58944
2021-07-20 08:13:30iritkatrielsetnosy: + iritkatriel
messages: + msg397861
2012-05-07 10:45:55georg.brandlsetnosy: + loewis, georg.brandl
2012-05-07 10:00:08serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg160128
2012-05-07 09:36:37larrysettype: enhancement
components: + Interpreter Core
stage: needs patch
2012-05-07 09:35:36larrysetassignee: larry
2012-05-07 09:35:09larrycreate