[PyQt] sip: Argument ambiguity

[Phil Thompson]

On Fri, 6 May 2011 08:39:11 -0700 (PDT), pymab <mabxsi at hotmail.com> wrote:
> Hi,
> 
> I'm currently experimenting with sip and my goal is to expose a C++
library
> with over 300 classes to python.  My first step is to expose the
core/base
> classes of the library. I'm having a problem with a particular class
> (CValue) which is basically a kind of variant class to handle multiple C
> types and object types.
> 
> So when parsing the CValue .sip file below, sip issues the following
error:
> sip: CValue has ctors with the same Python signature
> 
> class CValue
> {
> %TypeHeaderCode
> #include "xsi_value.h"
> %End
> 
> ...
> 	CValue();
> 	virtual ~CValue();
> 	CValue(const CValue& valSrc);
> 	CValue(LONG valSrc);
> 
> 	CValue(ULONG valSrc);
>>>	CValue(bool valSrc); 
> 	CValue(const CString& valSrc);
> 	CValue(const CRef& valSrc);
> 
> 	CValue(const CRefArray& valSrc);
> 	CValue(unsigned char valSrc);
>>>	CValue(signed char valSrc); 
> 	CValue(const CValueArray& valSrc);
> 	CValue(const CLongArray& valSrc);
> 	CValue(const CFloatArray& valSrc);
> 	CValue(const CVector3& valSrc);
> 	CValue(siPtrType valSrc);
> 	CValue(const siBlobType& valSrc);
> 	CValue(const wchar_t* valSrc);
> 	CValue(const char* valSrc);
> 
>>>	CValue(short valSrc); 
>>>	CValue(unsigned short valSrc); 
>>>	CValue(LLONG valSrc); 
>>>	CValue(ULLONG valSrc); 
>>>	CValue(float valSrc); 
>>>	CValue(double valSrc); 
> ...
> };
> 
> It seems like all the ctors marked with >> are conflicting. What is the
> best
> way to remove this ambiguity, should I go with argument annotation (i.e.
> Constrained) ? Or maybe there is a better way to do it ?
> 
> thanks
> -mab

/Constrained/ is only used to control Python's ability to convert types
(eg. to stop a bool being used when an int is allowed). It can't help when
there is no corresponding Python type, eg. distinguishing between float and
double.

The first question to ask is if you really need to make the distinction -
if not then just ignore the extra ctors. If you do then you could define
extra static factory methods and implement them with %MethodCode - no need
to change the library being wrapped. Another option would be to define a
new ctor that takes an additional argument that specifies how the value
should be interpreted.

Phil