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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
