"Martin v. Loewis" wrote:
>
> > Now this would be more flexible if you would implement a scheme
> > which lets us put the parser string into the method list. The
> > call mechanism could then easily figure out how to call the
> > method and it would also be more easily extensible:
> >
> > {"append", (PyCFunction)listappend, METH_DIRECT, append_doc, "O"},
>
> I'd like to hear other people's comment on this specific issue, so I
> guess I should probably write a PEP outlining the options.
>
> My immediate reaction to your proposal is that it only complicates the
> interface without any savings. We still can only support a limited
> number of calling conventions. E.g. it is not possible to write
> portable C code that does all the calling conventions for "l", "ll",
> "lll", "llll", and so on - you have to cast the function pointer to
> the right prototype, which must be done in source code.
>
> So with this interface, you may end up at run-time finding out that
> you cannot support the signature. With the current patch, you'd have
> to know to convert "OO" into METH_OO, which I think is not asked too
> much - and it gives you a compile-time error if you use an unsupported
> calling convention.
True. It's unfortunate that C doesn't offer the reverse of
varargs.h...
> > A parser marker "OO" would then call a method like this:
> >
> > method(self, arg0, arg1)
> >
> > and so on.
>
> That is indeed the plan, but since you have to code the parameter
> combinations in C code, you can only support so many of them.
>
> > allows implementing a generic scheme which
> > then again relies on PyArg_ParseTuple() to do the argument
> > parsing, e.g. "is#" could be implemented as:
>
> The point of the patch is to get rid of PyArg_ParseTuple in the
> "common case". For functions with complex calling conventions, getting
> rid of the PyArg_ParseTuple string parsing is not that important,
> since they are expensive, anyway (not that "is#" couldn't be
> supported, I'd call it METH_is_hash).
>
> > For optional arguments we'd need some convention which then
> > lets the called function add the default value as needed.
>
> For the moment, I'd only support "|O", and perhaps "|z"; an omitted
> argument would be represented as a NULL pointer. That means that "|i"
> couldn't participate in the fast calling convention - unless we
> translate that to
>
> void foo(PyObject*self, int i, bool ipresent);
>
> BTW, the most frequent function in my measurements that would make use
> of this convention is "OO|i:replace", which scores at 4.5%.
I was thinking of using pointer indirection for this:
foo(PyObject *self, int *i)
If i is given as argument, *i is set to the value, otherwise
i is set to NULL.
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
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