Re: inconsistency in Python SWIG return parameters

On Thu, Feb 27, 2003 at 04:53:44PM -0800, Marshall White wrote:
> (Speculation) My guess is that the SWIG interface functions must return SOME
> kind of Python object.

Any Python function must return an object; this is part of the "spec", if
you will for Python. If you don't have a value, then INCREF and return
Py_None.

> Setting "Py_None" right off the bat makes it the
> default in case of no other return values.

Right.

> I would also guess that
> returning NULL would be bad... The code seems to do that on error
> conditions.

Yup. For C implementations of a Python function/method/etc, returning a NULL
indicates that an exception has been raised. The caller can find that
exception stored in the per-thread state for the current Python interpreter
instances. That's mostly gobbledy-gook -- you can just call an accessor to
get the exception that was raised. The caller can also see the NULL and
simply propagate that to his caller, etc. Eventually, you'll get back to the
Python VM which will take the NULL result and begin the exception processing
at the Python level.

> I believe this whole problem would be relatively simple to work around IF a
> single-valued PyTuple is okay.

It is technically okay, but that means that all callers will be receiving
singletons. A major pain in the ass. For example, we have code such as:

    pool = svn.util.svn_pool_create(parent_pool)

That will no longer do what you think. "pool" will now be a singleton,
rather than a reference to the pool. The code would need to pull the value
out by doing something like:

    (pool,) = ...

or simply:

    pool, = ...

Either way... a pain.

But no matter for this particular case. I just posted what I believe is a
proper solution. This email is "educational", if you will, for all those
Python extension hackers out there :-)

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