gett error message: "TypeError: 'int' object is not callable"
Nick
Here is the code:
/code
file = open(prefix1)
text = file.readlines()
len = len(text)
fields = text[1].split()
num_rows = int(fields[1])
num_cols = int(fields[2])
U1_matrix = []
print fields
print repr(fields)
print len(fields)
for line in text[2: num_rows+2]:
fields = line.split()
# print "fields", fields, line
for i in range(len(fields)):
fields[i] = float(fields[i])
U1_matrix.append(fields)
/*code
prefix is a space/line delimited ascii file that represents a 2D
matrix. i'm trying to read in 2 matrices from different files, strip
away the header stuff and then take the dot product of the 2
matrices. any help is much appreciated.
thanks,
nick
Lutz Horn
Nick schrieb:
> I've seen a lot of posts on this problem, but none seems to help.
Could you please post a sample input file and the exact error message?
Thanks
Lutz
--
Strike Out ⇒ http://www.fourmilab.ch/documents/strikeout
Friðrik Már Jónsson
len = len(text)
You're overriding `len` (a built-in method), with an integer
(`len(text)`). You then call:
for i in range(len(fields)):
But `len` is no longer a callable, but merely an integer.
Regards,
Friðrik Már
P.S. While this is a fairly obvious problem it's usually a good idea
to post working code and a traceback when requesting help.
Richard Brodie
"Nick" <nlei...@gmail.com> wrote in message
news:e54c4461-c0b7-42fb...@h18g2000yqj.googlegroups.com...
> file = open(prefix1)
> text = file.readlines()
> len = len(text)
You have redefined two built-in functions "file" and "len" in the first three lines.
This is usually considered poor practice. Stick to meaningless variable names,
it's safer (only joking).
TypeError: 'int' object is not callable". This means that something you thought
was a function is in fact an integer. It's helpful to post/look at the line number of
the error; "how is this line failing", is much easier to answer than
"how is my program failing".
print len(fields)
Here len is an integer, because you redefined it in line 3. I'm guessing this is the
problem.
Nick
> "Nick" <nleio...@gmail.com> wrote in message
thanks for spotting the obvious errors, its my 2nd day programming
python in about 3 years.
fridrick, code should be workable with the exception of the
errors...thats the whole program
Thanks again for all the help problem fixed
Bruno Desthuilliers
> I've seen a lot of posts on this problem, but none seems to help.
> Here is the code:
> /code
>
> file = open(prefix1)
shadows the builtin 'file' type.
> text = file.readlines()
> len = len(text)
shadows the builtin 'len' function.
> fields = text[1].split()
> num_rows = int(fields[1])
> num_cols = int(fields[2])
>
> U1_matrix = []
>
> print fields
> print repr(fields)
> print len(fields)
And here's your problem - 'len' is now bound to the result of the
previous call to len(text).
Hint : Python's functions, classes and modules are objects too, and
don't live in a distinct namespace. So _don't_ use builtin's types /
functions / etc names as identifiers.
HTH
Dave Angel
your symptom.
Both 'file' and 'len' are defined in the standard library, and shouldn't
be redefined in your code. And your problem is that after you redefined
'len', you then tried to use it in its original meaning.
Rename those two and you'll get further.
And it would have saved lots of time for lots of people if you included
sample data and the actual error message, marking where in your code it
occurs. Once you know it's complaining about the len() call, it's not
too hard to figure out that the problem was you rebound the len
attribute from a function to an integer.
Traceback (most recent call last):
File "M:\Programming\Python\sources\dummy\echo2.py", line 21, in <module>
print len(fields)
TypeError: 'int' object is not callable
DaveA
Friðrik Már Jónsson
>> P.S. While this is a fairly obvious problem it's usually a good
>> idea to post working code and a traceback when requesting help.
Nick wrote:
> thanks for spotting the obvious errors, its my 2nd day programming
> python in about 3 years.
I'm sorry, my saying it was obvious may have come off a little
arrogant. My clumsily delivered point was that because it was a small
snippet of code it didn't take much time to run through for someone
who codes daily with Python. What you did there was a perfectly
ordinary thing to do until experience teaches you how Python does
things. :)
> fridrick, code should be workable with the exception of the
> errors...thats the whole program
You're right, I failed to say it explicitely but I was referring to
the input file. In some cases, albeit not this one, problems can
exist in parsing gotchas.
Regards,
Friðrik Már
Nick
years, but it was a simple and pretty obvious mistake. thanks for all
your help,
nick
Tom Kermode
Do you know a good way to avoid running into this problem? It
makes sense to suggest not calling variables the same names as
built-in functions, but that's hard for a new python programmer who
doesn't already know what all the built-in functions are. Over time a
programmer will learn which names to avoid, but it's a bit of a
pitfall early on.
Cheers,
Tom
2009/7/9 Richard Brodie <R.Br...@rl.ac.uk>:
Richard Brodie
"Tom Kermode" <tker...@gmail.com> wrote in message
news:mailman.2903.1247155...@python.org...
> Do you know a good way to avoid running into this problem? It
> makes sense to suggest not calling variables the same names as
> built-in functions, but that's hard for a new python programmer who
> doesn't already know what all the built-in functions are.
No, but not redefining the ones you actually use is a good start.
Learning to understand the traceback is the more important lesson,
IMHO. It takes a while to tune into what error messages are trying
to tell you; even when you stop making newbie mistakes, you're
going to have to deal with runtime errors from time to time.
Friðrik Már Jónsson
> Do you know a good way to avoid running into this problem? It
> makes sense to suggest not calling variables the same names as
> built-in functions, but that's hard for a new python programmer who
> doesn't already know what all the built-in functions are.
One way is using a code checker like PyChecker[1]. This neat software
for finding bugs will check for lots of other pitfalls too, but you
can filter it down to what you need if you're only interested in this
one.
I don't use an IDE, but this would seem like something for an IDE[2]
to support if you're into that kind of magic.
Regards,
Friðrik Már
[1] http://pychecker.sourceforge.net/
[2] http://wiki.python.org/moin/IntegratedDevelopmentEnvironments
Rhodri James
> Hi,
>
> Do you know a good way to avoid running into this problem? It
> makes sense to suggest not calling variables the same names as
> built-in functions, but that's hard for a new python programmer who
> doesn't already know what all the built-in functions are. Over time a
> programmer will learn which names to avoid, but it's a bit of a
> pitfall early on.
It's only really a pitfall if you try to use the built-in after you've
redefined it. That's the thing to keep an eye open for.
--
Rhodri James *-* Wildebeest Herder to the Masses
Friðrik Már Jónsson
> It's only really a pitfall if you try to use the built-in after you've
> redefined it. That's the thing to keep an eye open for.
You're right, but in cases where you're editing a codebase which you
didn't author entirely by yourself you may not be aware of that.
That said, if the codebase you're working on is structured (short,
concise methods) you should be working with small, consumable scopes
you can inhale in entirety before modifying.
Regards,
Friðrik Már
Simon Forman
<snip>
> fields = line.split()
> for i in range(len(fields)):
> fields[i] = float(fields[i])
instead of the above code you could say:
fields = [float(n) for n in in line.split()]
Have fun getting back into python! :] (A lot has changed in the last few years)
HTH,
~Simon
Paul Rubin
> text = file.readlines()
> len = len(text)
> fields = text[1].split()
Is that intended to split the first line of the file? Remember
that arrays in python begin at index 0.
Lie Ryan
But if you are responsible for a large codebase that you don't write
yourself, it is doubtful that you're a real newbie.
Lie Ryan
File "<stdin>", line 1
fields = [float(n) for n in in line.split()]
^
SyntaxError: invalid syntax
s/in in/in/
Nick
no the '1st line' is garbled meta data, but thanks man
J. Cliff Dyer
> Look at:
>
> len = len(text)
>
> You're overriding `len` (a built-in method), with an integer
> (`len(text)`). You then call:
>
> for i in range(len(fields)):
>
> But `len` is no longer a callable, but merely an integer.
>
> Regards,
> Friðrik Már
>
> to post working code and a traceback when requesting help.
While we're on the subject of good question posting form: The body of
your post should contain all relevant information. Please don't make
readers look back at the subject heading for the statement of the
problem. Duplicating the statement of the problem in the subject and
the body is ok, but it really ought to be in the body.