noob question: "TypeError" wrong number of args

[Holger]

Hi guys

Tried searching for a solution to this, but the error message is so
generic, that I could not get any meaningfull results.

Anyways - errormessage:
----------------------------------------------------
TypeError: addFile() takes exactly 1 argument (2 given)
----------------------------------------------------

The script is run with two args "arg1" and "arg2":
----------------------------------------------------
import sys

class KeyBase:
def addFile(file):
print "initialize the base with lines from this file"

print "These are the args"
print "Number of args %d" % len(sys.argv)
print sys.argv
print sys.version_inf o
print sys.version

f = sys.argv[1]
print "f = '%s'" % f
b = KeyBase()

b.addFile(f)
----------------------------------------------------

The output - including error message
(looks like stdout and stderr are a bit out of sync...):
----------------------------------------------------
These are the args
Traceback (most recent call last):

Number of args 3
['C:\\home\\<.. bla bla snip ...>\\bin\\test .py', 'arg1', 'arg2']
(2, 4, 2, 'final', 0)
2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)]
f = 'arg1'

File "C:\Program Files\ActiveSta te Komodo
3.5\lib\support \dbgp\pythonlib \dbgp\client.py ", line 1806, in runMain
self.dbg.runfil e(debug_args[0], debug_args)
File "C:\Program Files\ActiveSta te Komodo
3.5\lib\support \dbgp\pythonlib \dbgp\client.py ", line 1529, in runfile
h_execfile(file , args, module=main, tracer=self)
File "C:\Program Files\ActiveSta te Komodo
3.5\lib\support \dbgp\pythonlib \dbgp\client.py ", line 590, in __init__
execfile(file, globals, locals)
File "C:\home\hbille \projects\bc4ro m\bin\test.py", line 20, in
__main__
b.addFile(f)
TypeError: addFile() takes exactly 1 argument (2 given)
----------------------------------------------------

I'm running this inside ActiveState Komodo on WinXP.

Hope one you wizards can give me pointers to either what I'm doing
wrong or maybe advise me what to modify in my setup.

Thank you!

Regards,
Holger

[Fredrik Lundh]

Holger wrote:

Tried searching for a solution to this, but the error message is so
generic, that I could not get any meaningfull results.

Anyways - errormessage:
----------------------------------------------------
TypeError: addFile() takes exactly 1 argument (2 given)
----------------------------------------------------

The script is run with two args "arg1" and "arg2":
----------------------------------------------------
import sys

class KeyBase:
def addFile(file):
print "initialize the base with lines from this file"

when defining your own classes, you must spell out the "self"
argument in your method definitions:

def addFile(self, file):
print "initialize the base with lines from this file"

see:

http://pyfaq.infogami.com/what-is-self

</F>

[Holger]

oops, that was kinda embarrassing.
But thx anyway :-)

[Ben Finney]

"Holger" <is****@gmail.c om> writes:

----------------------------------------------------
TypeError: addFile() takes exactly 1 argument (2 given)
----------------------------------------------------

----------------------------------------------------
import sys

class KeyBase:
def addFile(file):
print "initialize the base with lines from this file"

You've misunderstood -- or never followed -- the tutorial, especially
how Python does object methods. Please follow the whole tutorial
through, understanding each example as you work through it. You'll
then have a solid basis of knowledge to go on with.

<URL:http://docs.python.org/tut/>

--
\ "We are not gonna be great; we are not gonna be amazing; we are |
`\ gonna be *amazingly* amazing!" -- Zaphod Beeblebrox, _The |
_o__) Hitch-Hiker's Guide To The Galaxy_, Douglas Adams |
Ben Finney

[Holger]

I guess I deserved that. :-(
I *did* read the tutorial, but then I forgot and didn't notice...
My brain is getting is slow - so thx for the friendly slap in the face
;-)

[Edward Elliott]

Holger wrote:

oops, that was kinda embarrassing.

It's really not. You got a completely unhelpful error message saying you
passed 2 args when you only passed one explicitly. The fact the b is also
an argument to b.addfile(f) is totally nonobvious until you know that 1) b
is an object not a module*, and 2) objects pass references to themselves as
the first argument to their methods. The syntax "b." is completely
different from the syntax of any other type of parameter.

The mismatch between the number of parameters declared in the method
signature and the number of arguments actually passed is nonobvious,
unintuitive, and would trip up anybody who didn't already know what was
going on. It's ugly and confusing. It's definitely a wart on the
langauge.

Making people pass 'self' explicitly is stupid because it always has to be
the first argument, leading to these kinds of mistakes. The compiler
should handle it for you - and no, explicit is not *always* better than
implicit, just often and perhaps usually. While it's easy to recognize
once you know what's going on, that doesn't make it any less of a wart.

* technically modules may be objects also, but in practice you don't declare
self as a parameter to module functions

[Steve Holden]

Edward Elliott wrote:

Holger wrote:

oops, that was kinda embarrassing.

It's really not. You got a completely unhelpful error message saying you
passed 2 args when you only passed one explicitly. The fact the b is also
an argument to b.addfile(f) is totally nonobvious until you know that 1) b
is an object not a module*, and 2) objects pass references to themselves as
the first argument to their methods. The syntax "b." is completely
different from the syntax of any other type of parameter.

Specifically, perhaps it would be better to say "b is an instance of
some Python class or type".

Objects don't actually "pass references to themselves". The interpreter
adds the bound instance as the first argument to a call on a bound method.

I agree that the error message should probably be improved for the
specific case of the wrong number of arguments to a bound method (and
even more specifically when the number of arguments is out by exactly
one - if there's one too many then self may have been omitted from the
parameter list).
The mismatch between the number of parameters declared in the method
signature and the number of arguments actually passed is nonobvious,
unintuitive, and would trip up anybody who didn't already know what was
going on. It's ugly and confusing. It's definitely a wart on the
langauge.
Sorry, it's a wart on your brain. Read Guido's arguments in favor of an
explicit self argument again before you assert this so confidently. It's
certainly confusing to beginners, but there are actually quite sound
reasons for it (see next paragraph).
Making people pass 'self' explicitly is stupid because it always has to be
the first argument, leading to these kinds of mistakes. The compiler
should handle it for you - and no, explicit is not *always* better than
implicit, just often and perhaps usually. While it's easy to recognize
once you know what's going on, that doesn't make it any less of a wart.
Hmm. I see. How would you then handle the use of unbound methods as
first-class objects? If self is implicitly declared, that implies that
methods can only be used when bound to instances. How, otherwise, would
you have an instance call its superclass's __init__ method if it's no
longer valid to say

myClass(otherCl ass):
def __init__(self):
otherClass.__in it__(self)
...
* technically modules may be objects also, but in practice you don't declare
self as a parameter to module functions

The reason you don't do that is because the functions in a module are
functions in a module, not methods of (some instance of) a class.
Modules not only "may be" objects, they *are* objects, but the functions
defined in them aren't methods. What, in Python, *isn't* an object?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[doobiz]

Just my opinion, but I think the Guido tutorial on Classes is
unintelligible unless you're coming from another OO language.

But I found something else that looks promising that you may want to
peek at:

http://pytut.infogami.com/node11-baseline.html

rd

[BartlebyScrivener]

No way. You didn't deserve it. Unless you came from another OO
language, the Guido tutorial on Classes is unintelligible. It assumes
way too much knowledge.

But I found something else that looks promising that you may want to
peek at:

http://pytut.infogami.com/node11-baseline.html

rd

Reply

[Edward Elliott]

Steve Holden wrote:

Objects don't actually "pass references to themselves". The interpreter
adds the bound instance as the first argument to a call on a bound method.
Sure, if you want to get technical For that matter, objects don't actually
call their methods either -- the interpreter looks up the method name in a
function table and dispatches it. I don't see how shorthand talk about
objects as actors hurts anything unless we're implementing an interpreter.

Sorry, it's a wart on your brain.
Fine it's a wart on my brain. It's still a wart.
Read Guido's arguments in favor of an
explicit self argument again before you assert this so confidently.
I would if I could find it. I'm sure he had good reasons, they may even
convince me. But from my current perspective I disagree.
It's
certainly confusing to beginners, but there are actually quite sound
reasons for it (see next paragraph).
While confusion for beginners is a problem, that's not such a big deal.
It's a trivial fix that they see once and remember forever. What I mind is
its ugliness, that the language makes me do work declaring self when it
knows damn well it won't like my code until I do what it wants (yes I'm
anthropomorphiz ing interpreters now). The interpreter works for me, I
don't work for it. Things it can figure out automatically, it should
handle.

Hmm. I see. How would you then handle the use of unbound methods as
first-class objects? If self is implicitly declared, that implies that
methods can only be used when bound to instances.
I fail to see the problem here. I'm taking about implicit declaration on
the receiving end. It sounds like you're talking about implicit passing on
the sending end. The two are orthogonal. I can declare
def amethod (a, b):
and have self received implicitly (i.e. get the object instance bound by the
interpreter to the name self). The sender still explicitly provides the
object instance, e.g.
obj.amethod (a,b)
or
class.amethod (obj, a, b)
IOW everything can still work exactly as it does now, only *without me
typing self* as the first parameter of every goddamn method I write. Does
that make sense?
How, otherwise, would
you have an instance call its superclass's __init__ method if it's no
longer valid to say

myClass(otherCl ass):
def __init__(self):
otherClass.__in it__(self)
...

Like this:
myClass(otherCl ass):
def __init__():
otherClass.__in it__(self)

self is still there and still bound, I just don't have to type it out. The
interpreter knows where it goes and what it does, automate it already!

* technically modules may be objects also, but in practice you don't
declare self as a parameter to module functions

The reason you don't do that is because the functions in a module are
functions in a module, not methods of (some instance of) a class.
Modules not only "may be" objects, they *are* objects, but the functions
defined in them aren't methods. What, in Python, *isn't* an object?

If it looks like a duck and it quacks like a duck... Functions and methods
look different in their declaration but the calling syntax is the same.
It's not obvious from the dot notation syntax where the 'self' argument
comes from. Some interpreter magic goes on behind the scenes. Great, I'm
all for it, now why not extend that magic a little bit further?