Lessons 22 and 23

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. : )


Lesson 21

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!

Woo-hoo! Another lesson down!

Lesson 20

At first glance, this exercise appeared simple for me, until I got into it a bit. First,

def print_all(f):

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:

print "Let's print three lines:"

current_line = 1
print_a_line(current_line, current_file)

current_line = current_line + 1
print_a_line(current_line, current_file)

current_line = current_line + 1
print_a_line(current_line, current_file)

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:
print_a_line(current_line, current_file)
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.


current_line = 1
while current_line <= 3:
print_a_line(current_line, current_file)
current_line += 1

FOUR LINES! So slim!

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!

Lesson 19

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!

amount_of_cheese = 10
amount_of_crackers = 50
cheese_and_crackers(amount_of_cheese, amount_of_crackers)

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)

number_of_things_boop = 20
number_of_things_doop = 30
function(number_of_things_boop, number_of_things_doop)

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!

Lesson 18

In this lesson, Mr Shaw introduces the idea of creating one’s own functions. Fortunately, I have plenty of experience with this and this exercise fazed me not much at all. It takes a moment to get my bearings considering what gets passed through to the defined functions, but it’s really not bad overall. I do see the difference again between Pythons 3.3 and 2.7 again, though, in the way that the arguments are inserted in a print statement via the %r rather than just exiting briefly out of what is being printed and just throwing the variable.

3.3 (what I am used to):
print(“The variable goes here:”, variablename,”.”)

2.7 (LPTHW)
print “The variable goes here: %r.” %variablename

Passing the parameters from the command line as arguments into the defined functions seems to make sense! **(Edit: nothing is passed from the command line to run the program, here. The arguments are defined within the program, not without.) Since a function just does whatever you tell it to (I suppose the same could be said of literally anything you punch into a future program), its structure and formatting does not elude me, especially since we made lots of them when I was knee-deep in 3.3.

And how exciting! He has a big red warning, “don’t worry if you are confused,” well, I am not! Yay! I know I will keep having other troubles down the line, but this one is pretty ok!

The Common Student Questions area advises me to try to break if it I seem bored 🙂 so that is what I did! I passed an argument into a function without using it in that newly defined function, and it wigged out – perfect! I don’t think 3.3 cared if you used the parameter/arg/var passed in, but 2.7 does, and that is sensible and easy to synthesize.

Lesson 17

Ok! I started this lesson a few weeks ago. Each week I work on programming for just a few hours at PyLadies PDX and go about my business the rest of the week, sometimes coming back to whatever I’m working on during the week, but typically I have enough that keeps me occupied and away from programming Sunday through Friday.

This lesson has been difficult to get through all of the Study Drills of, as I’m having a hard time reducing the code by much, other than just taking out the print statements. I don’t see the need to count the length of the .txt file or to run the EXISTS function, but I also don’t see a need to omit them. He leaves a hint in the Common Student Questions that you ; can ; make ; a ; statement ; one ; line if you want to, but… I have never used semicolons in Python, just C++ (via a few chapters of Michael Dawson’s wonderful book), and I fail to see the good of obfuscating one’s code for sake of just making it one line, as Mr Shaw suggests he can do, I suppose, by separating the lines with a semicolon rather than a return, if that is even possible.

I am also still getting the hang of ARGV, the function that permits me to insert files into the program from the command line. It is not too complicated, it is just not something that I have seen before, and flub it up still on occasion. All the same I see its usefulness and look forward to being able to use it more effectively.

So I shall move on!

Learn Python the Hard Way, Lessons 1-16

Being nominally familiar with Python, these first lessons went by in a breeze. The biggest hiccup (if you can call it that) was going through the Command Line Crash Course, also written by Zed Shaw (the gent who wrote LPTHW). It was enormously helpful but took me approximately a week to get to the level of knowledge that I wanted. I did not finish it as I was very impatient to get back to lovey-woo-woo python, but my facility with the command line is prrrrobably as good as I’ll need it for the time being.

Several lessons went by per sitting, working things out with very satisfactory comprehension, until I got to Lesson 13! Lessons 13, 14, 15, and 16 have all begun to tax me much more than previous lessons, which is to be expected.

It’s odd, I can do all kinds of looping & sub-looping and data structures (with some effort) in Python 3.3, but in 2.7 my knowledge is developing completely laterally to that kind of capability. What that really means, at least to me, is that I am actually gaining new knowledge rather than just learning the formatting for while loops with 2.7’s idiosyncrasies and moving on. It is great.

One complaint that I have heard regarding Mr Shaw’s tone is that he is a bit short and a bit arrogant in that way that programmers are known to be. If this description is too vague for you, then you fortunately have not been over-exposed to this kind of attitude. I am a bit refreshed by his tone, however, because I find that he is right, and learning from someone with that kind of confidence in what he or she is teaching is totally instrumental in my absorption of the material, personally. Besides, I like a little sass, and I like a little old-school-style coding education.

Ok! Enough prelude! At this time, I’m at lesson 17, so let’s move on to that! “Next entry, please!” is what I know you are saying!