Re: [Swig-user] python and int + bool function overloads

[William S F. <ws...@fu...>]

On 18/03/10 19:29, William S Fulton wrote:
> Guillaume Buisson wrote:
>>>> Josh Cherry wrote:
>>>>> On Thu, 4 Mar 2010, Guillaume Buisson wrote:
>>>>>
>>>>>>>> Having in c++
>>>>>>>> void doIt(bool value) ;
>>>>>>>> void doIt(int value);
>>>> I don't think so given the improvements that Guillaume posted earlier.
>>>> He is suggesting to use PyBool_Check, which when I tried it will accept
>>>> True and False as bools, but not 0, 1, 42, etc. To me it looks that if
>>>> PyBool_Check is used instead of PyObject_IsTrue, it is enough to sort
>>>> out the overloading of bool and other integer types.
>>> OK, but doing that generally would have another effect that is
>>> arguably bad.  Suppose you have
>>>
>>> void foo(bool value);
>>> void foo(double value1, int value2);
>>>
>>> Then foo(1) in Python won't work.  The equivalent in C++ would work,
>>> and arguably it should work in Python too.
> If it is any help, both Java and C# accept boolean types (true, false)
> as acceptable values in the wrappers and not integers (0, 1). This might
> be different to C++, but then there isn't always an identical one to one
> match with C++ in many areas for any of the languages.
>
> This illustrates the issue that
>>> the cast/rank mechanism was supposed to get around.
>>>
>>> Josh
>>
>> I agree: it is not great. But python has an actual native Boolean
>> type, we should use it as such...
>>
>> It is bad to lose a functionality (foo(bool) and foo(int) work as
>> expected) to gain something (in your example foo(1) instead of
>> foo(True)) that is, maybe good, maybe not.
>>
> To me it makes sense to fix this to use proper boolean types. This might
> mean you can't pass an integer to a SWIG wrapped function taking a bool
> when you previously could; users would have to use a Python type
> conversion: bool(x) where x is a number. Not hard, but possibly breaking
> some existing code.
>
> The next version of SWIG will be a big version change - 2.0.0 and this
> would be the right time to change this behaviour. There are other small
> subtle changes in behaviour in this version compared to 1.3.40.

This change never went into SWIG 2.0.x. I'm thinking of putting this 
change into SWIG-3.0.0 which is just around the corner. Any objections?

William