[Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
larry at hastings.org
Tue Dec 4 20:04:09 CET 2012
On 12/04/2012 01:08 AM, Antoine Pitrou wrote:
> Le Mon, 03 Dec 2012 14:29:35 -0800,
> Larry Hastings <larry at hastings.org> a écrit :
>> dbm.open -> mapping
>> const char *filename;
>> The filename to open.
> So how does it handle the fact that filename can either be a unicode
> string or a fsencoding-encoded bytestring? And how does it do the right
> encoding/decoding dance, possibly platform-specific?
> I see, it doesn't :-)
If you compare the Clinic-generated code to the current implementation
of dbm.open (and all the other functions I've touched) you'll find the
"format units" specified to PyArg_Parse* are identical. Thus I assert
the replacement argument parsing is no worse (and no better) than what's
currently shipping in Python.
Separately, I contributed code that handles unicode vs bytes for
filenames in a reasonably cross-platform way; see "path_converter" in
Modules/posixmodule.c. (This shipped in Python 3.3.) And indeed, I
have examples of using "path_converter" with Clinic in my branch.
Along these lines, I've been contemplating proposing that Clinic
specifically understand "path" arguments, distinctly from other string
arguments, as they are both common and rarely handled correctly. My
main fear is that I probably don't understand all their complexities
Anyway, this is certainly something we can consider *improving* for
Python 3.4. But for now I'm trying to make Clinic an indistinguishable
> I like the idea, but it needs more polishing. I don't think the various
> "duck types" accepted by Python can be expressed fully in plain C types
> (e.g. you must distinguish between taking all kinds of numbers or only
> an __index__-providing number).
Naturally I agree Clinic needs more polishing. But the problem you fear
is already solved. Clinic allows precisely expressing any existing
PyArg_ "format unit"** through a combination of the type of the
parameter and its "flags". The flags only become necessary for types
used by multiple format units; for example, s, z, es, et, es#, et#, y,
and y# all map to char *, so it's necessary to disambiguate by using the
"flags". The specific case you cite ("__index__-providing number") is
already unambiguous; that's n, mapped to Py_ssize_t. There aren't any
other format units that map to a Py_ssize_t, so we're done.
** Well, any format unit except w*. I don't handle it just because I
wasn't sure how best to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev