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 <t...@resophonic.com>
To: Development of Python/C++ integration <cplusplus-sig@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
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
