There is a trivial one-line fix for this, which I'll paste below. I've tested the fix and would like to have submitted a pull request, but I am unable do so due to proxy restrictions at work.

The problem arises when you have an overloading situation like the following:

void SomeFunc(int param1, int[] param2);void SomeFunc(int param1, int param2, int param3);

and you make a call like SomeFunc(1,2,3).

During overload resolution, if pythonnet encounters an overload with fewer parameters than are supplied in the call, but whose last parameter is of array type, it assumes that the last parameter is a "params" array. i.e. it treats the first overload above as if it were declared:

void SomeFunc(int param1, params int[] param2);

The result is that pythonnet calls the first overload and passes the second and third arguments as a 2-element array in param2, when it should be calling the second overload and passing all three arguments normally. (The actual situation we are experiencing is more complex, but the above example should reproduce the behaviour.)

The fix belongs in methodbinder.cs. At line 271, there is the following code:

} else if ((pynargs > clrnargs) && (clrnargs > 0) &&(pi[clrnargs-1].ParameterType.IsArray)) {// The last argument of the mananged functions seems to// accept multiple arguments as a array. Hopefully it's a// spam(params object[] egg) style method

This needs to be changed to explicitly check for the case of a params array. The following replacement works for me:

} else if ((pynargs > clrnargs) && (clrnargs > 0) &&               Attribute.IsDefined(pi[clrnargs-1], typeof(ParamArrayAttribute))) {