From: William S F. <ws...@fu...> - 2014-03-07 08:46:04
|
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 |