Jack Jansen <Jack.Jansen@oratrix.com> writes:
> How about taking a completely different angle on this matter, and
> looking at PyArg_Parse itself? If we can keep PyArg_Parse 100%
> backward compatible (which would mean that its "i" format would take
> any IntObject or LongObject between -1e31 and 1e32-1) and introduce a
> new (preferred) way to parse arguments that not only does the right
> thing by being expressive enough to make a difference between
> "currency integers" and "bitmap integers", but also cleans up the
> incredible amount of cruft that PyArg_Parse has accumulated over the
> years?
I had a similar idea, so I'd encourage you to spell out your proposal
in more detail, or even in an implementation.
My idea was to provide a ParseTuple wrapper, which would be like
int
PyArg_ParseTupleLenient(PyObject *args, char *format, ...)
{
char format1[200];
int retval;
va_list va;
for(int i = 0; format[i]; i++)
format1[i] = lenient_format(format[i]);
va_start(va, format);
retval = PyArg_VaParse(args, format1, va);
va_end(va);
return retval;
}
This would replace the "i" format with a "k" format, and perhaps make
other changes to the format.
Those of you needing to support older Python releases could
#define PyArg_ParseTupleLenient PyArg_ParseTuple
in your distribution, or provide other appropriate wrappers.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4