What I do to prepare for a "day of Python" is to read through the chapter while sitting well away from a computer. I just read the pages and plan out what I will be doing and noticing areas where I know I will struggle. That way, when I'm back at the computer with Downey's book Think Python, I know the direction in which I'll need to travel and will be aware of the potholes and speed bumps in the road.
"Math functions. Why did it have to be math functions?" Chapter 3 introduces modules, which are files that contain the definitions of the functions and variables related to the module. But while Downey includes a bit of trigonometry (well beyond my skills as a mere writer), this chapter doesn't require the reader to actually do any trig (thankfully). For the sake of "mathphobic" people like me though, it would have been nicer if Downey had inserted another module to use as an example. On the other hand, after importing math, I can use "math.pi" in a statement without having to specifically define pi.
Chapter 3 is also the first time when the reader will have to compose or put together when they've learned in previous chapters, particularly Chapter 2. After reading the chapter, I actually go through the pages sitting at my computer and practicing what I'm reading as I blog (I haven't encountered Exercise 3.1 yet) and I think this helps map the concepts to the practice somewhat. Maybe more examples or practice exercises per concept would be useful, at least to me, when trying to "glue" an idea to an action (thinking of a function vs. writing a function). As of page 27, I've got a program, if you can all it that, containing two function definitions: "print_lyrics()" and "repeat_lyrics()" (more Monty Python fun and games). Now I need to write a script containing those definitions and use the script for the first two exercises.
For the first time, Downey mentions text editors (in the Debugging section) that are "aware" of Python and its "indentation needs," but he doesn't suggest any. Fortunately, gedit, which I regularly use in Ubuntu, lets you select which program or format you need including Python, so I'm OK there...sort of, as it still doesn't do indentation automatically. But the reader who knows absolutely nothing about this will be at a loss.
I forgot to end one of my strings with a double-quotation mark and also forgot that in the shell, to execute my script, I had to type "python repeat_lyrics.py" instead of just "repeat_lyrics.py." Once I corrected those little fubars, my wee script ran. Now on to Exercises 3.1 and 3.2. I guess you can change the order of function definitions and still have the program run OK. But these two exercises were absolutely benign next to what I knew was coming later.
I also had a heck of a time getting the first function in the Parameters and Arguments section of the chapter to work until I defined "bruce," which wasn't made explicit in the text. I did it wrong, since I treated the parameter "bruce" like a variable, but it worked. I wasn't satisfied however, completely exited from the shell, opened a new shell, and finally got it to work. I'll never know what I did wrong the first time, though.
I mentioned stack diagrams before and they're tricky because, at least as far as the example in Chapter 3 goes, they're read from the bottom up. The natural human tendency is to read from the top down. On the other hand, I'm a highly visual person, so it does help to have a picture to follow when trying to remember lots of little details, like parameters and variables inside a function.
There were a few concepts that were introduced but I'm not sure how much I was expected to understand. Pages 30 and 31 talked about __main__ as a built-in Python function and None as a special value (None comes back to haunt me later). After this, I was "treated" to information that seemed a little more digestible such as "Why Functions?" which I thought should have been at the beginning of the chapter, and how to import from within a module such as "from math import pi" rather than importing all of the math module with, "import math".
The Debugging section primarily addressed the various problems you can run into with text editors, although it still would have been nice if Downey would have expressed a preference. Maybe he wants his readers to "think outside the book" and do that investigation themselves. I dunno. The Glossary section is especially handy for people like me who have problems connecting concepts and "jargon" with what they actually do. But then, I'm stalling, because I'm living in dread of the Exercises section. Will I be able to successfully navigate the three remaining exercises without either cheating or giving up?
No. I cheated. I found the answer for Exercise 3.3 (I won't tell you where) and the problem made a sort of sense when I saw the answer. I copied it into a script and ran it and it worked. I think most of the required information was contained in the chapter, but I obviously don't "think like a computer scientist" because I couldn't intuitively put it together, even with the clue Downey inserted in the question for the exercise.
Actually, even after looking up the answers (or what were supposed to be the answers) for Exercise 3.4, they still don't make sense. This is typically where I get stuck trying to learn to program, think like a computer scientist, or whatever you want to call it. In a classroom setting (which is where I appear to belong), I could always tuck my tail between my legs and slink off to the instructor's office to ask what I'm doing wrong, but working alone (with everyone who reads this blog watching) at home, it doesn't quite work out so well.
Allen, are you out there?
Original Article: Tracey Pilone's recent blog at O'Reilly.com,