AHH. Feels good to be back to ordinary python (though I now have much more planned for heroku/django!). Today I wanted to punch out a quick lesson since it’s been a few weeks for a Learn Python the Hard Way, and I want to maybe finish the book by the end of the year. Here’s exercise 26, a debugging exercise. Excellent. *cracks fingers* Ok! First, I copied in the required “code” from here into nano & immediately set to correcting all the tiny errors, like missing parentheses, spelling errors (not that those matter too much in this exercise but pedantic habits die hard), and inconsistencies with function naming/calling. I knocked this out in about fifteen minutes. Exciting!! I should do another, even though it’s thanksgiving eve & that bathroom isn’t going to clean itself 🙂 ok but yeah just one more for real, this didn’t quite scratch the itch! and then I’ll get to the bathroom, jeez DAD LAY OFF
Edit: OH MY GOD THE NEXT EXERCISE IS TRUTH TABLES! HOORAY!!
Here we’re getting into writing programs to be used, actually used, on the command line, and that is so exciting. It’s been almost seven months since I made something to actually use, and while I have no real need for a sentence sorter, to have written a program that I can then manipulate in the py shell is REALLY REALLY NEAT, to me.
At first, I struggled a bit with some of the definitions, but I really enjoy separating the definitions from the actual what-you-want-it-to-do-ness of the program, as it were 🙂
Seeing this: def print_first_word(words):
"""Prints the first word after popping it off."""
word = words.pop(0)
"""Prints the last word after popping it off."""
word = words.pop(-1)
was pretty exciting, as I recall the idea of “pop”ping from the approximate third of Douglas Hofstadter’s Gödel, Escher, Bach: An Eternal Golden Braid that I read, in one of the interchapter dialogues. Pushing and popping have a very clear analogue in computer science, and while, looking at this particular exercise of Mr Shaw’s, I think that it is not actually the same idea, ha ha! it is still a nice callback even if unintentional and unrelated!
One of the Common Student Questions for this exercise, too, was “what is the difference between print and return, and his answer is somewhat crummy, emphasis mine:
When should I print vs. return in a function?
You need to understand that print is only for printing to the screen and that you can actually do both print and return a value. When you understand this then you'll see that the question is kind of a pointless question. You use print when you want to print. You use return when you want to return.
So I do not really have a clear idea. It seems like once the function has done f(banana) to the stuff, you can either return the result or print it. return seems more verb-y, but the end result seems identical. I will have to read about this!
As a whole this was not a challenging exercise, but it was really fun. I love that Zed Shaw focuses on being able to manipulate python via the structure-level command line rather than via an IDE, like the very popular IDLE which I will not link here. I’ve never imported a function in the shell to play with, and I feel like the possibilities have just expanded. Yeah!
Last week, I completed lesson 24, which was a “make sure you know how to do x, y, and z” exercise of no new material – a fine cap to the no-new-exercises triad of 22, 23, and 24. I am, to be honest, super bored by the idea of not doing new things while going through these lessons and have sped through these fairly quickly.
I am already planning what I’ll do next, after LPTHW. Probably pre-emptive, but there is so much out there and it’s hard not to speculate what I’ll want to do next. I like Zed Shaw’s style and might do the Learn Ruby The Hard Way module, but I might do Learn You A Haskell for Great Good! next because a) Haskell is apparently very sexy right now, and b) it’s probably a good idea to go through a different kind of tutorial than just The Hard Way. Though Ruby might be more career-helpful if I should ever want to make something of this (fairly long-invested at this point!) hobby, so we shall see.
Ok! These were sorta boring! 22 said “go back over everything and make sure you know it,” essentially, and because I am impatient, I went through all the previous lessons in around an hour, surprised at how much I have actually absorbed. Then I moved speed-quick over to the 23rd exercise, which says to look up code and see if you can understand it, so I did a bit of that, and now I am again quite anxious to get back to regular lessons. : )
Moving along, here! This lesson was mostly a refresher on function ordering, for me. At the very end, there is an extra credit portion where he recommends resolving a nested set of functions by hand before running the program.
print "Here is a puzzle."
age = add(30, 5)
height = subtract(78, 4)
weight = multiply(90, 2)
iq = divide(100, 2)
what = add(age, subtract(height, multiply(weight, divide(iq, 2))))
print "That becomes: ", what, "Can you do it by hand?"
I knew that it was necessary to resolve inner parentheses before moving on to the next inner set of parentheses as just a giant composed function, but once I got to the non-commutative operations (ie, subtraction and division, in which order of operation matters) I flubbed it up a bit, and came up with a different answer than when I ran the program. Then I examined it a bit, and with a bit more analysis (that’s an overly heady word for it, ha ha!) in the form of the following:
age = add(30, 5) #35
height = subtract(78, 4) #74
weight = multiply(90, 2) #180
iq = divide(100, 2) #50
and then resolved the commutativity issue, I came up with the same answer that he did! woo-hoo!
At first glance, this exercise appeared simple for me, until I got into it a bit. First,
That f throws me! I tried to see in the code what it was doing, but I couldn’t, and besides, the point of each lesson is to teach NEW ideas, not expect the student (that’s me!) to understand the language of code intuitively – otherwise, hey, who needs lessons?
So I didn’t understand that right at first, but that’s okay, because further on, we’re given:
Hey! Awesome! Given my experience with looping, whether WHILE or IF and maybe some other type I am forgetting right now, I can see a mile away that this can be WAY cleaned up per my specifications! This hugely makes up for the not-knowing of the utility of f previously!
So I go ahead and run the program, something that will print out a text file line by line as well as “rewinding” it, and then I set immediately to cleaning it up:
i = 0
current_line = 1
while i < 3:
current_line += 1
i += 1
Woo-hoo! Nine lines condensed down to six, and while that may not sound like much, a) it can probably be condensed more, and b) it’s a much simpler process, at least for me, to follow. I am thinking I may not even need the i indexing!
Let’s play around, then, a bit. I’m going to take out the i index and make the while loop dependent on current_line rather than on the index.
One last thing: re the f code question from before, well, it was addressed by Mr Shaw in the Common Student Questions portion! The f acts like a VHS-style “read head,” as in, the reading of the file stops at the line you read, and then our defined function rewind moves it back to the position we specify, in this case, the 0th byte, a.k.a. the beginning of the file!
EDIT of 13 October 2013: It occurs to me that altering variables is not the best practice for looping. Rather than adding values to current_line, it is a better idea to create an index like i and set current_line equal to the index, and then let the index do all the heavy lifting! Then, if I want to call the variable again, it will be unchanged! Woo-hoo!
Hoo-whee, we are really getting into it now, aren’t we! I know this blog is only a week old, but I’ve been working on Learn Python the Hard Way for just shy of two months, and that I’ve gotten through 19 lessons is quite exciting for me! Getting somewhere, even if I am not being assessed – now THERE’S adulthood! Well, maybe it’d be more adult if it wasn’t just so fun!
This exercise deals more with the introduction to writing and using one’s own functions, just like last time.
def cheese_and_crackers(cheese_count, boxes_of_crackers):
print "You have %d cheeses!" % cheese_count
print "You have %d boxes of crackers!" % boxes_of_crackers
We start out by defining cheese_and_crackers, a function that prints out a few statements with the given variables. Just a skosh down the road, we start putting values in for cheese_count and boxes_of_crackers, but suddenly! ack!
Now we’re calling cheese_count by the name of amount_of_cheese! WELL. The neat thing here is that in defining the function, we’ve named it something convenient for ourselves, but when we refer to it later, the var should be called something else, to distinguish from the name/s given in the initially defined function. Follow me here:
def function(thing_a, thing_b)
print "here's the %s things and the %s other things" % (thing_a, thing_b)
So that last bit calls the function itself, to which the variables .._boop and .._doop are passed, and since the function initially requires two variables, any two passed in there will then be given the roles of thing_a and thing_b given in the function. Hoo! I have read this paragraph aloud to myself several times, and I think that it makes sense?
So that’s Lesson 19, and it’s also the lesson in which I learned about the html code tag! The explanation is much lengthier than my understanding would have given, but I’m really pleased to have ironed it out so thoroughly, at least for myself. Crystal clear, now!