-1

Our tool has python embedded. We defined a function which takes 'two' arguments (but only one user argument):

def code(self, device):
        return tools.code(self, device)

Everything works well when they actually call the function with one argument:

code(device)

The problem arises when a user makes a call without any arguments at all eg:

code()

Now the error message returned by the python interpreter is: 

TypeError: code() takes exactly 2 arguments (1 given)

Now the user thinks there should be 2 arguments, when in fact they only need to provide one - is there a way to improve this error message?

ftl25
  • 51
  • 1
  • 6
  • yeah, do device='' in the parameters of the function – Leifingson Nov 22 '13 at 03:17
  • Why is this confusing? Your function code requires an argument for device. Would it be confusing if you called math.pow with only one argument? –  Nov 22 '13 at 03:28
  • It's confusing to the end user because really they need to provide only one argument, not two. – ftl25 Nov 22 '13 at 03:33
  • +1 Don't know why this gets downvoted. The implied self- actually, the error message- is confusing to newcomers to Python. The error message makes it worse, because it should be: `code() takes exactly 2 arguments (1 implied, none given).` See [Why explicit self has to stay][1], Guido mentions "I agree that this is confusing, but I would rather fix this error message...". [1]: http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html – Mike S Oct 14 '15 at 20:31

1 Answers1

-1

To elaborate on my comment..

If you're calling the method, self is implicit. That counts as one argument. And you have another parameter named device. That is the other argument, hence it expects two arguments. If at some point you want to accept no arguments aside from the implicit self argument, you can use *args like this:

def code(self, *args):

Or you can use a default value for the parameter like this:

def code(self, device=''):
Leifingson
  • 180
  • 8
  • How is setting a default better? That turns bad error message -> silent bug. Var-args isn't any better – daniel gratzer Nov 22 '13 at 03:25
  • I didn't say it was better. I have no idea what their intentions are of returning it, and I'm not willing to make assumptions – Leifingson Nov 22 '13 at 03:30
  • But in what possible scenario is it better to just silently ignore an error? The question is about improving the error message, not sweeping it under the rug – daniel gratzer Nov 22 '13 at 03:31
  • What I want here is for the error message to be clear to the user. The user doesn't know about the implicit 'self', and when they see 'needs two arguments' they don't know what the extra one might be. – ftl25 Nov 22 '13 at 03:32
  • Okay, disregard my post then. The "Are we doing something wrong in our code?" made me think you didn't understand what was happening, not that you were asking how to change the exception string sent to the user. You could catch a TypeError, check its value to ensure it's raised because of an argument mismatch, and then print something different. However, I don't recommend this. And users that are confused about these exceptions shouldn't be seeing that part if it were designed properly. – Leifingson Nov 22 '13 at 03:48
  • "If it were designed properly"- that's why I'm asking. What is the correct design? – ftl25 Nov 23 '13 at 01:22
  • Actually, all I did need to do was to set the default value in the param list. We actually have some error handling in place (raising a type error and showing a nice message), but it was never getting to that because python failed it first. So @Leifingson - this worked perfectly for what we need: `def code(self, device=None)` – ftl25 Dec 12 '13 at 03:19