[C++-sig] strange behavior with respect to numeric and Booleanoverloads

[troy d. straszheim]

Ralf W. Grosse-Kunstleve wrote:
> I checked in (svn rev. 52299) Troy's patch with an additional condition, e.g.:
> 
> #if PY_VERSION_HEX >= 0x02040000 && defined(BOOST_PYTHON_BOOL_INT_STRICT)
> 
> I.e. the default behavior is unchanged, but people can add -DBOOST_PYTHON_BOOL_INT_STRICT
> to experiement.
> 
> When I did this in my project, it took me several hours to correct bool/int mismatches.
> I also had to introduce a special trick to easily make bool arrays (mainly for unit tests),
> e.g. before it was array.bool([0,1,0,1]) but now it is array.int([0,1,0,1]).as_bool().
> Because if things like this, I decided it is best not to make the new behavior the default.

Agree with the decision to #ifdef it... This might be worse than 
first-match, and the overload-order-bug has been around a long time 
without surfacing.  It'd be hard to justify going that direction.  Note 
that exactly the same situation exists for float and int, see

https://svn.boost.org/trac/boost/browser/trunk/libs/python/test/test_overload_resolution.cpp

which I checked in but didn't enable in the jamfiles.  call each of 
those overloads functions with bools ints and floats and you get 
different results.  So maybe there's a call for 
BOOST_PYTHON_STRICT_OVERLOADS, or somesuch.  I dunno.

> 
> Ideas: Maybe we'll have a comprehensive overload solution after the summer, which will mean
> the current patch and the define will be obsolete.
> If not, it may be best to turn the compile-time choice into a runtime choice, similar to
> the docstring options (http://www.boost.org/doc/libs/1_38_0/libs/python/doc/v2/docstring_options.html).
> 
> I could do that if necessary.

So with strict checking turned *on*, you disambiguate manually:

   foo(bool(1), 'hi')

but turning on strict checking breaks all kind of stuff.  For the vast 
majority of cases, it seems, what's there is fine.  So either grok and 
implement something like d. wallin / luabind's method, as dave suggests.

Meanwhile, just riffing a little bit:  maybe give the user a way to dig 
a particular overload out of the function.  So if foo is overloaded so:

    void foo(int, std::string);
    void foo(bool, std::string);

and both are wrapped, and I'm in python and want the second one, how about

    foo[ (bool, string) ](1, 'hi')

where the bracket operator essentially returns the one exact-matching 
overload of foo for the type arguments provided.  Or something.
This makes overloading a leaky abstraction to some degree (you have to 
know c++ details to choose your overload), but then again they're 
already foreign to python; this would be for emergency cases.

(moments later) After writing all that I'm inclined to have a closer 
look at the luabind implementation.

-t


> 
> Ralf
> 
> 
> 
> ----- Original Message ----
> From: troy d. straszheim <troy at resophonic.com>
> To: Development of Python/C++ integration <cplusplus-sig at python.org>
> Sent: Thursday, March 19, 2009 12:27:56 PM
> Subject: Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads
> 
> Ralf W. Grosse-Kunstleve wrote:
>> The comprehensive solution sounds like a project. Do we have someone to work on this?
>>
>> I'm asking because I think Troy's proposed simple solution is better than the status quo.
>>
> 
> I'm willing to work on it.  I'd have to look at Daniel W's code to see if I want to push back on the simple solution or not... haven't done that yet.  Maybe we want to get Haoyu thinking about this in the background, as well, he might be done with py3k support before the end of the gsoc summer.
> 
> -t
>