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?
Hi James. I have been holding off on commenting because I don't want to ruin your experiment. But your articles are incredibly helpful for me.
ReplyDeleteI see a lot of places where I can make improvements in the book based on where you are having problems.
The particular error you posted is a good one. It looks like this is the line of code that's failing:
do_four(print_twice('spam'))
This is a nested function call, so the inner one happens first. print_twice prints 'spam' twice and then returns None. So the value that gets passed to do_four is None. But the value passed to do_four needs to be a function, so if you give it None, it fails.
The exercise says that do_four should take two parameters, a function object and a value, so when you call it, it should look like this:
do_four(print_twice, 'spam')
I will leave you to write the definition for do_four.
By the way, I really like your idea of reading the book once away from the computer before you sit down to program. It sounds like you are doing everything right.
Hang in there; I think you will find Chapter 4 more fun.
James --
ReplyDeleteI too learned the basics of python by reading Think Python and worked through these examples. I can tell you that when you first learn to program it can be very intimidating! Stick with it! The more you try and apply previously learned concepts, the more you understand them! If you think you are more of an auditory/visual learner as opposed to a textual learner, I suggest you check out CS101 at udacity ( http://www.udacity.com/overview/Course/cs101/CourseRev/apr2012 ). However I would still very much recommend you keep reading Think Python because it covers a lot of important information and thinking strategies that udacity skips over. I hope you keep continuing with your 19 days of Think Python. Everyone runs into mistakes and blocks when learning to program, it's just part of how one learns.
Hi James, hang in there. :)
ReplyDeleteYou can also check out this interactive version of the book, http://interactivepython.org/courselib/static/thinkcspy/Functions/functions.html. You can run all the code directly off the page, modify a few parameters to experiment with, and see the results right away. if you choose to create an account, you can also save your code separately from the 'gold version'. A short video instruction is here, http://runestoneinteractive.org/.
I, too, tried to learn how to write a few lines of code after a chosen profession many years after. I had given up multiple times and swing wildly between different languages over the years before settling on Python. The key for me between my failed attempt to finally learn some basics was to remind myself to have fun. Really, that was what it took. I learned to use a formal schedule as a guideline instead of feel like falling behind when I got stuck, I learned to purposely sidetrack myself when I see something fun and interesting I go off the topic to explore the topic and only come back to the book when I am ready. Also, whenever I see something I can apply to work, I do it right away and feel like I have 'done something' once I finish a small script or what not. Focusing on the benefit (help me do my job and have fun) instead of the feature (Python/Perl, functions, loops, String) kept me going and motivated.
Cheers and thanks for sharing. It is not always easy to expose your weak moments, takes a confident person to do just that. :)