> 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.
I wouldn't say it is a bug, more a missing feature. Dave and I knew about the drawbacks from the start, but we didn't have the time for the comprehensive solution. I've been using Boost.Python heavily for 8+ years now, and it has only been a few times that I found the simple first-match solution annoying. In the worst case, you just give the overloads different names in Python. (I don't know how easy this is with Py++, though.) > It'd be hard to justify going that direction. Note that exactly the > same situation exists for float and int, There is an important difference: int and float are numeric types. bool really isn't (I think it is highly undesirable that bool and int are implicitly convertible in Python and C++). In a very early stage of the Boost.Python v2 reimplementation, even str matched float or int! bool matching float or int is similar, only we couldn't do anything about it since bool didn't exist as a type in Python 2.2, which is all we had during the v2 reimplementation. > So with strict checking turned *on*, you disambiguate manually: > > foo(bool(1), 'hi') > > but turning on strict checking breaks all kind of stuff. It wasn't that bad for me, just a little boring having to retrofit the mountains of old code. The end-result is cleaner, so it's worth it. But it think it would be bad to force it on people. We need a soft approach, so that everybody can do it at his own schedule. > 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. I haven't thought about this very much at all, so this may be stupid: Could the C++ template matching rules be a role model? These rules are time tested and I believe are very well spelled out. > and both are wrapped, and I'm in python and want the second one, how about > > foo[ (bool, string) ](1, 'hi') That seems like it could be a lot of work to implement, and it would be very unusual. You can achieve the same via: foo_int_string(1, 'hi') foo_float_string(1, 'hi') In the few cases that I had the int/float problem, on second thought it turned out to be better to use more telling (different) names for the functions. I.e. I never found myself resorting to appending the argument type names. Another nice solution is to disambiguate via keywords. Ralf _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
