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

[Bruno Desthuilliers]

Marc 'BlackJack' Rintsch a écrit :
(snip)

Okay, let's start with writing a simple text processor for this little
mess::

def b(c):
def d(r, *s, **t):
print '***'
c(r, *s, **t)
return d

What a nice, readable, highly pythonic code...
(snip)

[Ben Finney]

Edward Elliott <no****@127.0.0 .1> writes:

As long as we're trotting out aphorisms
The ones I quoted were from Python.

import this

how about DRY: Don't Repeat Yourself. The rule couldn't be clearer:
don't repeat your SELF. ;) Yet that's exactly what explicitly
declaring self does, forces me to needlessly repeat what everyone
already knows: methods take the object instance as their first
parameter.

You've misunderstood "don't repeat yourself". It advocates *one*
definition of any given thing in the code. You are advocating *zero*
definitions of 'self' in the code.

--
\ "No wonder I'm all confused; one of my parents was a woman, the |
`\ other was a man." -- Ashleigh Brilliant |
_o__) |
Ben Finney

[Ben Finney]

Bruno Desthuilliers <bd************ *****@free.quel quepart.fr> writes:

Ben Finney a écrit :

So now you're proposing that this be a special case when a
function is declared by that particular syntax, and it should be
different to when a function is created outside the class
definition and added as a method to the object at run-time.

Thus breaking not only "explicit is better than implicit",

This one can be subject to discussion.

All the assertions in 'import this' are subject to discussion. They're
even contradictory.

but also "special cases aren't special enough to break the rules".

Yeps, I think this is what I don't like here.

Still -1.

I'm not yet ready to vote for Edward's proposition - as you say, it
makes 'def statements into a class statement' a special case, and I
don't like special cases too much (OTOH, there actually *are*
special cases - __new__() being an example) - *but* it's not that
silly either IMHO, and I think this should not be dismissed on a
purely reactional basis.

My basis for rejecting the proposal is that it claims to offer net
simplicity, yet it breaks at least two of the admonishments that
simplify Python.

--
\ "My house is made out of balsa wood, so when I want to scare |
`\ the neighborhood kids I lift it over my head and tell them to |
_o__) get out of my yard or I'll throw it at them." -- Steven Wright |
Ben Finney

[Edward Elliott]

Ben Finney wrote:

Edward Elliott <no****@127.0.0 .1> writes:

As long as we're trotting out aphorisms
The ones I quoted were from Python.

>>> import this

Yes I know where it's from.
You've misunderstood "don't repeat yourself". It advocates *one*
definition of any given thing in the code. You are advocating *zero*
definitions of 'self' in the code.

It's implicitly defined by the language/runtime, so I shouldn't need to
define it in my code. Doing so is duplication of effort, aka DRY. An
implicit definition is not an empty definition. Where do the semantics of
'while' and 'for' come from? Same thing, it's implicit in the language.

[Edward Elliott]

Ben Finney wrote:

My basis for rejecting the proposal is that it claims to offer net
simplicity, yet it breaks at least two of the admonishments that
simplify Python.

As do other features of Python. Or did you forget the follow-up to the
special cases "rule"?

Special cases aren't special enough to break the rules.
Although practicality beats purity.

[Edward Elliott]

Marc 'BlackJack' Rintsch wrote:

Edward Elliott wrote:

I can prove that assertion too: make a simple text processor that reads
Python source code and outputs the same source code with only one change:
insert the string 'self" as the first parameter of every "def
somemethod". Next run the output source code with the normal Python

Okay, let's start with writing a simple text processor for this little
mess::

I didn't even try to wade through that morass of monocharacter variables.
Anyone wanna summarize the point of that code?

[Ben Finney]

Edward Elliott <no****@127.0.0 .1> writes:

Marc 'BlackJack' Rintsch wrote:

Edward Elliott wrote:

I can prove that assertion too: make a simple text processor that
reads Python source code and outputs the same source code with
only one change: insert the string 'self" as the first parameter
of every "def somemethod". Next run the output source code with
the normal Python

Okay, let's start with writing a simple text processor for this
little mess::

I didn't even try to wade through that morass of monocharacter
variables. Anyone wanna summarize the point of that code?

As I understand it, the point was not what the code does, but to give
a sample input (a Python program) for the "simple text processor" you
described to wade through.

--
\ "I always had a repulsive need to be something more than |
`\ human." -- David Bowie |
_o__) |
Ben Finney

[Edward Elliott]

Ben Finney wrote:

As I understand it, the point was not what the code does, but to give
a sample input (a Python program) for the "simple text processor" you
described to wade through.

Ah, well then, there's no need for a full-blown parser. It should suffice
to recognize a class definition and modify the parameter list of every def
indented one level further than that. Then pick out the static methods and
'undo' those. Can be done in one pass by keeping the class definition in
memory until you've scanned the whole thing, then adding self where needed
as you spit it back out.

Implementation is left as an exercise for the reader. :)

[bruno at modulix]

Ben Finney wrote:

Bruno Desthuilliers <bd************ *****@free.quel quepart.fr> writes:

Ben Finney a écrit :

So now you're proposing that this be a special case when a
function is declared by that particular syntax, and it should be
different to when a function is created outside the class
definition and added as a method to the object at run-time.

Thus breaking not only "explicit is better than implicit",
This one can be subject to discussion.

All the assertions in 'import this' are subject to discussion.

Of course - but that was not the point. I meant that having implicit
self in methods would not break this assertion much more than the
current strange mix of explicit declaration of self + implicit passing
of self.
They're
even contradictory.

That's the nature of Zen, isn't it ?-)

(snip)

I'm not yet ready to vote for Edward's proposition - as you say, it
makes 'def statements into a class statement' a special case, and I
don't like special cases too much (OTOH, there actually *are*
special cases - __new__() being an example) - *but* it's not that
silly either IMHO, and I think this should not be dismissed on a
purely reactional basis.

My basis for rejecting the proposal is that it claims to offer net
simplicity, yet it breaks at least two of the admonishments that
simplify Python.

One could also claim that the current scheme *actually* breaks
explicit-implicit and special-case rules in that the instance is
implicitely passed at call time for the bound methods special case -
which is ok IMHO since practicallity-beats-purity. Also, FWIW, Edward's
proposition can be justified (at least that's Edward's POV) by the first
rule : beautiful is better than ugly !-)

disclaimer : None of this is to be taken as the expression of my own
position on this proposition...

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[bruno at modulix]

Edward Elliott wrote:

Ben Finney wrote:

As I understand it, the point was not what the code does, but to give
a sample input (a Python program) for the "simple text processor" you
described to wade through.

Ah, well then, there's no need for a full-blown parser. It should suffice
to recognize a class definition and modify the parameter list of every def
indented one level further than that.

won't do :

class CounterExample( object):
if compute_some_co nst_according_t o_phase_of_moon ():
def meth(...):
do_something(se lf, 42)
else:
do_something_el se(self)

Then pick out the static methods and
'undo' those.

don't forget classmethods...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"