[C++-sig] boost::python overload resolution redux

[troy d. straszheim]

troy d. straszheim wrote:
> 
> That doesn't work for pure python functions either:
> 
>  >>> def f(x,y,z): return x*100 + y*10 + z
> ...
>  >>> from functools import partial as p
>  >>> p(f,x=1)(2,3)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: f() got multiple values for keyword argument 'x'
>  >>> p(f,x=1)(y=2,z=3)
> 123
>  >>> p(f,1)(2,3)
> 123
> 
> The error message is misleading for sure.  Boost.python is going through 
> a list of overloads and trying them in order; if it runs out of 
> overloads, it says nothing matched.  I think I can get it to be smarter 
> about this, lemme see...
> 

Trac ticket here:  https://svn.boost.org/trac/boost/ticket/3710

For the record, here's a variation on the same theme.  It doesn't have 
anything to do with functools, it is another symptom of our first-match 
overload resolution algorithm:

int addem(int x, int y, int z) { return x*100 + y*10 + z; }

BOOST_PYTHON_MODULE(functools_playnice_ext)
{
   def("addem", &addem, (arg("x"), arg("y"), arg("z")));
}


 >>> from functools_playnice_ext import addem
 >>> addem(1, 8, 2, x=4)
Traceback (most recent call last):
...
ArgumentError: Python argument types in
     functools_playnice_ext.addem(int, int, int)
did not match C++ signature:
     addem(int x, int y, int z)


I've been thinking about this off and on for a while, to fix it right 
isn't trivial.  I could put in a few checks for cases where a function 
is not overloaded, but that feels like hackery.


-t