This is available in 1.2 as
object *
PyEval_CallMethod(object *obj, char *methonname, char *format, ...)
(didn't you once suggest this? I do listen :-)
But note that the list append method is also available as addlistitem
in 1.1 (renamed to PyList_Append in 1.2).
> I'd also like to see:
>
> - 'Call' functions that allows arguments to be passed in as a
> varargs list (rather than requiring a tuple be built).
Actually that's the one I have here.
> - Ideally, 'Call' ops also provide conversion from C->Python
> automatically, via a mkvalue format list. This gets close to
> the embedded-call API ideas, but here the function is a python
> object or an object's method, not a user-defined item.
Well, that would be a really trivial combination of [new]getargs
(PyArgs_ParseTuple) and *CallMethod. I'm not sure if it's worth
defining lots of functions that are shorthands for calling two other
functions. I'd rather keep the set small and powerful.
> - A more complete definition. For instance, there's no easy
> way to build a tuple; above, I built a list, set item 0,
> and then convered to a tuple. But Tuple_New seems useless:
>
> PyObject *args = PyTuple_New(1);
> <how to set a tuple's item here: sq_ass_item not defined?>
>
> Of course, I could revert to the tuple's C functions, but
> this defeats the purpose. These functions aren't tuple
> 'methods', so there's no way to get to them as object Attr's.
Well, since you are creating a tuple it looks like it's no great sin
to use the tuple specific functions on it, i.e. settupleitem() (in 1.1
terminology; PyTuple_SetItem in 1.2). That's not part of Jim's
proposal only because it already exists.
--Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>