|
From: Stefan Z. <sz...@gm...> - 2011-07-23 05:16:11
|
On Fri, Jul 22, 2011 at 3:35 PM, John McFarland <mcf...@gm...> wrote:
Is there a reason that that is the intended behavior for the case of
> optional1 below but not optional2 (both have a default value for x)?
>
Looking a bit more closely at the code, it appears that SWIG tries to use
default args in the python code whenever doing so will allow SWIG to avoid
generating overload resolution code for the method. In this case, SWIG
doesn't recognize that optional2 meets that criterion. The code it
generates is still correct, but it's perhaps not ideal.
> I don't know what you mean by the "default typemap" or that it will convert
> Py_None to NULL. The issue is that in the C wrapper code, the PyObject*,
> say obj0, may be either a NULL pointer or Py_None after calling
> PyArg_ParseTuple, depending on whether swig decided to use *args or not.
> Swig automatically protects the typemap with a check like:
> if (obj0) {
> {
> // Some typemap code
> }
>
'Some typemap code' is actually a call to SWIG_ConvertPtr, which will
recognize Py_None and convert it to NULL for passing to the C++ method.
Stefan
|