On Thu, Feb 27, 2003 at 04:10:56PM -0800, Dale Hirt wrote:
> First shot across the bow:
>...
> if (target == NULL)
> {
> target = PyTuple_New(1);
> PyTuple_SetItem(target, 0, o);
> }
> /* If we pass in a Py_None arg, it must be the first time through.
> * We would have already created a tuple by now and populated it,
> * so we'll decrement Py_None, and then we'll create a new tuple,
> * and make the first item = o
> */
> else if (target == Py_None)
> {
> Py_DECREF(Py_None);
> target = PyTuple_New(1);
> PyTuple_SetItem(target, 0, o);
> }
These two blocks can be:
if (target == NULL || target == Py_None)
{
Py_XDECREF(target);
target = PyTuple_New(1);
PyTuple_SET_ITEM(target, 0, o);
}
>...
> if (!PyTuple_Check(target))
> {
> o2 = target;
> target = PyTuple_New(1);
> PyTuple_SetItem(target, 0, o2);
> }
> o3 = PyTuple_New(1);
> PyTuple_SetItem(o3, 0, o);
Switch to PyTuple_SET_ITEM() for performance.
One problem with this, however, is that the t_output_helper() behavior
enables you to have a non-tuple return value. The SWIG wrappers will set the
result to Py_None -- there are no "void" functions in Python; you actually
return None if something explicit was not returned. When a typemap specifies
that a value is to be returned, then t_output_helper() is used to
"concatenate" it with the *current* "result". If the current was Py_None
(because that is how it was initialized), then the return value is simply
this new value -- no tuple. But if you have a multi-valued return, then the
second call will construct the tuple.
Obviously, that breaks down when the first value might be Py_None.
But in your new helper, single-valued functions will return a one-tuple. I
don't think that is very nice, so I'm not sure we can use this approach.
This all looks good, but I also wonder whether we couldn't just use
Py_BuildValue() to construct the return value for certain multi-valued
return functions.
Not sure if we can. I'll see if I can find something...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 28 01:53:54 2003