>> > PyObject* PyObject_CallMethod(object, method-name, args...)
>>
>> I like it. I should have included it. I'm for adding it. How about a
>> family of routines:
> [...]
> The 1.2 release defines PyEval_CallMethod with the semantics of
> your PyObject_CallMethodStringV. This may be a bit confusing.
> Actually, it makes no sense to have both a callable_object and a
> method object as parameter -- a callable object doesn't take a method,
> and a method itself is already a callable object.
Argh..That was a typo. The CallMethod functions take objects with
methods; they do not require callable objects. I had it right in 4
out of the 6 cases. :-|
> And since passing
> the argument list as a tuple is only one call away from just using
> PyEval_CallObject(), why not just have to variants:
> - PyEval_CallFunction(object *callable_obj, char *format, ...)
> - PyEval_CallMethod(object *obj, char *methonname, char *format, ...)
> This would correspond to your 'C' family of functions. Again, the 'V'
> family is easily emulated using the 'C' family and a format string
> like "OOO", so there really is no pressing need for that many
> different variants.
I buy that. We don't need the 'V' family. I don't think these are Eval
things. We aren't invoking the parser. Are you suggesting we have:
PyObject_CallObject(PyObject *callable, PyObject *args_tuple)
PyEval_CallFunction(object *callable_obj, char *format, ...)
PyEval_CallMethod(object *obj, char *methonname, char *format, ...)
?
>> Call the method named m of object o. Special method names,
>> such as "__add__", "__getitem__", and so on are supported.
>> Arguments are given by the tuple, args. If no arguments are
>> needed, then args may be NULL. Returns the result of the
>> call on success, or NULL on failure. This is the equivalent
>> of the Python expression: o.method(args).
> Should "__add__" etc. work for built-in object types (e.g. integers)
> too? That would be nice but lots of work, since it isn't implemented
> currently.
It woudn't be that much work. I'd first try to get the attribute. If
that failed, I'd check a dictionary of special attributes. If the
attribute that is not found is special, then I'd try to call the
special function. This can be done without much code.
> Also, since the vast majority of these calls would have
> constant string literals for this argument, it would encourage users
> to write
> z = PyEval_CallMethod(x, "__add__", "o", y)
> instead of the more efficient and direct
> z = PyNumber_Add(x, y)
Hm. But it seems more consistant somehow to treat all methods
uniformly. Of course, then one might also expect
PyObject_AttrString(o,"__add__") to return a Python-callable object,
which might be a bit of a pain, and would not be consistent with the
behavior of the interpreter.
>> Also, to handle conversion of the output of this and other functions
>> returning PyObject pointers to C, I suggest:
>>
>> PyArg_ParseTupleD(PyObject *o, char *format, ...)
> (== PyArg_ParseTuple followed by Py_DECREF(o)).
> While I like the semantics of checking for NULL and then leaving an
> existing exception (which I suppose could be made the standard
> semantics of PyArg_ParseTuple), again I don't like defining a new
> function as a shorthand for two other calls.
But it could be an extremely common two calls. It also eliminates the
need for a temporary variable, which I think is a bigger win. The
difference is between, say:
PyArg_ParseTupleD(PyObject_CallMethod(foo,"bar","fi",2.5,9),
"i",&j);
and
PyArg_ParseTuple(spam=PyObject_CallMethod(foo,"bar","fi",2.5,9),
"i",&j);
XDECREF(spam);
or perhaps:
spam=PyObject_CallMethod(foo,"bar","fi",2.5,9);
PyArg_ParseTuple(spam,"i",&j);
Py_XDECREF(spam);
I prefer the first case myself. I think it's worth the extra function.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.