strange/misleading function signature in error messages when using named parameters

General Usage
1

I wrote a function with the following signature: function setOptimStatus(patientID::Int, status::String; rcProject::PyObject=0, repeatInst::Int=0).

When called with two parameters, I get the following error message:

ERROR: MethodError: no method matching #setOptimStatus#37(::Int64, ::Int64, ::#setOptimStatus, ::Int64, ::String)                      
Closest candidates are:                                                                                                                
  #setOptimStatus#37(::PyCall.PyObject, ::Int64, ::Any, ::Int64, ::String) at /path/source.jl:xxx

I find the function signature in the error message misleading, since it states 5 parameters, while the function only has 4. Moreover, the parameters are in strange order: (3, 4, X, 1, 2), where X is the additional/dummy parameter.

Is this meant to be so, or is it a bug? (And if the latter, should I report it?)

By the way, to remove the error, all I needed to do was to change the third parameter to rcProject::PyObject=PyObject(0), because otherwise it converts the value to Int … which I also find strange: since the parameter is specified to be of type PyObject – is this a bug?
Instead, I would expect one of the following to happen:

  • 0 gets converted to PyObject(0) automatically and everything works
  • I get an error that 0 cannot be converted to PyObject(0) … ideally during compilation, instead of runtime, but that is probably just my C++-brain talking…
2

Your expectations are not yet entirely calibrated for the way Julia does stuff. You have specified the type of the second function argumet as PyObject. That is a specific kind of thing. Generally, the quiet conversion of a zero to a PyObject, while unsurprising to the Python programmer, is not desireable (it opens up the possibility of badness that goes unnoticed).

3

#setOptimStatus#37 is not the function you wrote, it is an “anonymous” function created by the compiler to deal with the keyword arguments.

4

I understand that argument - but then it should complain that the default argument has wrong type (and, again, this should/could be caught by the compiler), instead of ignoring the specified type and converting it to Int.

5

But why should I be interested in error message from a function that compiler created? Is there no way for the compiler to formulate the error message in terms of the function I actually wrote?

6

Yes, it’s confusing. There are a couple of issues open for it, e.g. 13599. Presumably it is nontrivial to fix.

7

With Julia, it is useful first to consider solving software tasks in terms of the clarity of their expressed types and the patterns of dispatch which most adroitly serve.

You should not be specifying that an argument must be of a specific type and simultaneously giving it a default value of some other type. Our frame.

8

Thanks for the link. Another relevant issue is 16490.
At least I know that this is considered an issue and, hopefully, worked on.

9

Again, I agree that I “should not be specifying that an argument must be of a specific type and simultaneously giving it a default value of some other type” - all I am asking for is that this explanation as an error message, instead of a complaint about a non-existing function.

1 Like
10

That error message does not reflect an underlying design decision (all I know).