Ok, it’s starting to get pretty complex! As best as I can understand it at the moment, a class is a a sort of super structure that can be used more flexibly than can a simple function, that other variables and structures can be flexibly swapped in and out of. I am fairly lost on a good amount of the syntax, like the __init__ and the self.name = name, to name a few. But I’ve decided to go ahead and start copying in the code for this exercise, though I don’t entirely understand it yet. Evidently it always takes a long time to really grok OOP. So that’s ok.
Some things I notice: The classes call a generic object seem to be hierarchically above others, e.g. class Scene(object) (rather than class Death(Scene) which calls Scene()). I don’t know if this is important or not, but it is how Zed’s exercise is going.
And at this point, I’ve pushed through, even not being totally sure of what I’m doing, and punched in all the code, learning snippets here and there, and I’ve checked it all over, and it doesn’t run. I am frustrated. I have read the last few exercises several times where he has started discussing classes and object-oriented programming, and I’m really not getting the hang of it. Someone told me, when I shared that I was trying to start learning what the meat and potatoes of modern programming, OOP, really is, that it took learning another language before he really grokked what the deal was. Barring that, I just keep trying to read about it. I know I can get it, but I don’t have it right now, and I can’t finish this lesson of LPTHW, and I’m frustrated. So I shall move on and try to come back later.
Hey-o, conditional statements! I breezed through a bunch of lessons because we’re getting back to the kind of programming that I have already learned quite well. For the novice, my blog will not be as helpful as it may have been for previous lessons. The issue is that I am super ready to finish LPTHW!
For Exercise 29, he introduces conditional statements, the results of which I could see as I typed them in.
people = 20
cats = 30
if people < cats:
print "Too many cats! The world is doomed!"
if people > cats:
print "Not many cats! The world is saved!"
Basic less-than/greater-than operators – clearly the world is doomed! That’s about all there is to this exercise. (Ed: T.I.L. that less than and greater than symbols have to be inserted into with & l t ; and & g t ;, respectively! Awesome!)
In Exercise 30, it’s the same thing but introducing, hmm, subconditional statements you might call them? Rather than just if and else there’s also elif which takes its place before the final else in which you can make a further conditional statement within the if statement. This has been one of the handiest things I have learned (though I learned it long before this lesson) in Python, and it has analogues in every other programming language as well. Very cool.
In Exercise 31, the conditional statements get wrapped up in a “game” in which your player gets to choose from various options, to either be driven mad by Cthulhu or ripped apart by a bear. HMMM, which would you choose?? The purpose of this lesson is to start getting the student comfortable with nested if-statements. Old hat for me – I need to move a little faster!
With that, I think I need to go through these lessons a little more quickly than I want to blog about. I will write another blog when I come up against something that is truly new to me. I know Zed Shaw has challenges for me yet!
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!