[Tutor] Building Starships -- object of type 'int' has no len()

Terry--gmail terry.kemmerer at gmail.com
Mon Aug 18 01:48:57 CEST 2014


WOW! There is a lot of help on this mailing list! I want to thank 
everyone for their valuable input! Thanks!  (I am working my way through 
the replies.)

Sorry about the HTML. I think I have it turned off now in Thunderbirdy 
for this address. If so, then what follows should not be flat. If it is 
flat, please tell me.

The problem portion of the program now works, as I have corrected where 
my strings were getting converted to integers. However, if it is OK. I'd 
like to discuss and ask a few questions on a few things that have been 
brought up.

Mark:

You commented on the non-Pythonic nature of my program. HA HA HA! I 
don't doubt it!

I am coming from a BASIC background based on line numbers and GOTO and 
GOSUB statements, and when I read this book on Python I am sure I 
understood it in terms of that old BASIC. Hence, my nested FOR 
statements have been laid out in layers as I did it in this Python 
program because that is how I envisioned those statements through BASIC 
eyes. BUT, they might also have looked something like:

30 FORX=1TOZ:FORC=1TOE:<do something here>:NEXTE:NEXTZ

The fact is, I am VERY interested in acquiring that 'Pythonic' view you 
mention and I have encountered that term bandied about on the Internet, 
but have come away confused as to exactly what Pythonic Thinking really 
is! The writers seem to take it for granted I know. I don't.

After all, the way I laid the code out in my program is actually 
functional. So, I am really curious about the benefit of a Pythonic Way, 
and what it looks and reads like...

Is their a Pythonic Table anywhere on the Internet, where various 
possible coding methods in Python are contrasted to the real Pythonic 
Way? -So I can examine and study the contrasted structure to understand 
what the Pythonic Structure is accomplishing? (Maybe I am asking the 
wrong question here.)

I must confess that I had, when first writing the code to discover the 
maximum size of each column for later print to screen, searched the 
Internet for a python statement or an import of some kind that I could 
simply hand my block of data to, and have it come back with the maximum 
sizes of the columns. (Yes. I'm an optimist! :) ). But, I did find the 
below piece of code which sounded like it was doing what I wanted, so I 
tested it and then integrated into my program:

lens = [max(map(len, col)) for col in zip(*catalog2)]


It worked great! So I kept it (as a thing of utter beauty) as I was awed 
by it. -until I started getting that syntactic error pointing to that 
line. The problem is, I didn't understand the commands within the above 
statement (max, map, zip, and the * usage) and how they were 
interactively accomplishing things (the statement was utterly over my 
head at this juncture), and when it came to debugging, after a few 
embedded print statements failed to tip me off to the problem and the 
bug persisted, I kept suspecting the statement......so I decided to 
replace the above code with something that was very familiar and 
understandable to me (albeit, not a thing of pythonic beauty):

lens = [0] * len(catalog2[0])

for line_number in range(len(catalog2)):

for col in range(len(catalog2[line_number])):

if lens[col] < len(catalog2[line_number][col]):

lens[col] = len(catalog2[line_number][col])


-And was surprised to discover the same bug persisted! The situation 
buffaloed me into thinking there was something about the language I was 
not comprehending in this section, when the actual problem, as we 
discovered, was elsewhere.....some of the string data had been converted 
to integers, and thus expecting a string instead of an integer, I got 
the Type Error.

But I am now very curious to see how this same coding would be 
accomplished in a Pythonic Way, so, letting the statement you gave me 
redefine the entire flow of thought in that area of code--

catalog2 = [

["Drives", "Type", "Price", "Max Speed", "Energy Drain", "Rq-Crew", "", 
"", ""],
["Drives", "Solar Sail", "3", "1", "None", "2", "", "", ""],

["Drives", "Bussard Ramjet", "10", "7", "2", "3", "", "", ""],

["Drives", "Fusion", "70", "15", "5", "8", "", "", ""],

["Drives", "Matter-Antimatter", "1500", "145", "15", "13", "", "", ""],

["Drives", "Warp Drive", "2500", "250", "45", "17", "", "", ""],

]


We want to find the maximum size for each column--

lens = [0] * len(catalog2[0])

for line_number, row in enumerate(catalog2):
for col, item in enumerate(row):
if lens[col] < len(item):
lens[col] = len(item)

print(lens)


[6, 17, 5, 9, 12, 7, 0, 0, 0] <<-----that is the correct answer.


Did I do this correctly? Or, was there a way to compact it more?


What have we gained?


We have grabbed the entire row of data, and then looped through it 
without setting indexes when referring to the parts of each line...thus 
less clutter. Did we do this because there is less overhead generated as 
we sweep through the data?


It is the same number of lines, BUT there is less typing in most of the 
lines.


Do we anticipate an execution speed increase doing it this way also?


Or have we altered the way we think to fit a Pythonic Way of structuring 
that will help us with other portions of the language??? (Does the 
pattern of it become more easily readable at a glance after we have 
gotten used to it?)

Thanks!
--Terry



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140817/35f0c805/attachment-0001.html>


More information about the Tutor mailing list