[Python-Dev] parser markers vs. conversion functions (unicode/string asymmetries)

[M.-A. Lemburg]

"Martin v. Loewis" wrote:
> 
> > 2. What would be the corresponding unicode format character for 'z'
> > in the struct module (string or None)?
> 
> You mean, in getargs? There is no corresponding thing.
> 
> I'd recommend against adding new formats. Instead, I'd propose to add
> new conversion functions:
> 
>   Py_UNICODE *str;
>   PyArg_ParseTuple(args, "O&", &str, PyArg_UnicodeZ);
> 
> int PyArg_UnicodeZ(PyObject *o, void *d){
> ...
> }

Why do you think that adding the conversion functions to getargs.c
would be any different from adding new parser markers ? 

As I understand "O&", it is meant for user-space conversion functions, 
not system provided ones. The latter can easily be intergated as 
parser markers or options to parser markers. Unless, of course, you 
want to start shifting from parser markers to conversion functions 
completely (which I doubt).

Note that "O&" doesn't really buy you anything much: you could
just as well use "O" and then switch on the returned object
type or call a converter (with all the extra error handling
or other extra information needed for your particular case).
 
> It may be desirable to allow passing of : or ; strings to conversion
> functions, and helper API to format the errors.

You'd need a new parser marker option to support this new 
interface.

In the end, I don't believe we gain much from beefing up the
"O&" interface. I'd rather like to see the Unicode parser
markers extended to be more useful (I'll checkin a patch for
"u#" later today).

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/