Skip to content

Intro to Python – Week 1 – Musings

About class (and teaching/learning programming):

In Week 1 we covered functions, the modulo operator, comparisons, and if/elif/else. They offer a tool called “Pystep,” where you can see functions being evaluated. I am not sure whether it is actually more helpful or more confusing to someone who is unfamiliar with programming, but it’s a cool idea and another way to try to visualize what’s going on. Similarly, they talked about functions in terms of “black boxes.” As an engineer, that’s super intuitive to me, but I find myself really curious about whether that made sense to anyone who’s new to programming. I do remember finding truth tables really confusing when I was in school, and I looked away while he was going through them in this class—I think it’s related to my (mild!) dyslexia. I evaluate complex Boolean statements really well, but I don’t do it with tables. I wonder if truth tables make sense to most people, though.

Honestly, I’m thinking I’d start a group of librarians with True/False and comparators, before I even went into the other operators. Librarians are pretty familiar with Boolean logic—something that the newbies who are non-librarians might have some trouble with, at first—but, for a librarian, that part should feel like home and should help build up some early confidence.

I wonder how non-librarians who haven’t programmed before felt about the quick intro to comparators. It was … speedy.

Anyway, back to class: the assignment was to build Rock-Paper-Scissors-Lizard-Spock. I was kind of sleepy, which always makes my dyslexia worse, so once I had it written, it was a little hard to evaluate whether I got it right or not. I dread doing the peer evaluations for that reason. But it was a pretty good, simple starting project—assuming you caught the part of the lecture where he told you how to do the clever modulo trick. (You assign a number to each one, when they’re arranged in a certain order. Then, to determine who wins, you take the difference modulo 5. If it’s 1 or 2, it’s a win; if it’s 3 or 4, it’s a loss. — I’m not breaking the honor code by saying this here; I’m quoting the professor nearly word-for-word. I know because I had to go back and watch that part of the lecture again.) Honestly, my plan when I heard about this assignment was to power through a bunch of if/elif/else statements. I would never have come up with the modulo thing on my own, and although I’m prepared to blame sleepiness/dyslexia for it and assume it would have made sense on a different day, I’ll come clean and admit that I barely understood why it worked. I just did as I was told and made sure everything evaluated appropriately.

Once again, the quiz was unnecessarily mathy. “Build functions,” (great, yes!) “out of these equations” (REALLY?). Is that necessary? One equation-question might have been OK, but there were three. Why not string operations? Grr.

Now that I’m writing this, I have to say, I feel a little … paternalistic? … complaining about the math on others’ behalf. I don’t know for certain that anyone found programming equations particularly daunting. It just seems like there might be a more approachable way to assess people’s understanding of the programming concepts, given that math-phobia is fairly common and well documented. Maybe I’m focusing on this too much, though.

About Python itself:

One project in, I am starting to understand why people like Python. At first, it was pretty weird trying to program without braces (I always call them “brackets,” for some reason) or semi-colons. But the code reads a lot like English. It’s just… super neat. I’ve never gotten joy from a programming language before—a job well done, despite the language, or a clever solution to a problem, sure, of course, but never the language itself. It’s pretty amazing.

My only complaint so far is “Why elif? Why not else if, or elseif?” Well, and perhaps Python’s unnecessary respect for programming history, in (apparently?) usually counting zero to n-1, instead of zero to n. (For Python aficionados who will have more perspective than I do, here’s where this comes from: somewhere in his assignment or documentation or somewhere, the professor claimed that that doing ranges the way random.randrange() does (x <= N < y) is more common in Python than doing x <= N <= y, like random.randint() does.) It won’t cause me any future problems, because the zero to n-1 pattern is internalized for me, but it’s a weird choice for an otherwise readable language. I nearly turned in the assignment with an off-by-one error, because I was floating on a Python cloud and assumed it would handle things intuitively for a non-programmer. To be fair, I suppose that’s on me, not on the language.

So now I find myself wondering… can people get paid for writing in Python? :)

Published inclassesgeekeryprogrammingtechnology


  1. Good point on strings v. numbers. I just pulled up the last 3 programs (scripts really) that I touched at work. They are all full of nothing but string manipulation (and for loops, but Python’s foreach will cover up the numbers under the hood there.) Oh, wait; I also split a string, and validate the _number_ of pieces. And here, I look at a substring, offset by a _number_. So *almost* nothing but strings, but even the numbers are all *about* strings.

    I’m sure somewhere out there, someone is writing scientific code, or is writing a new graphics engine, and actually has to code up functions that deal with a lot of numbers. But a lot of programmers on a lot of days will only ever touch strings.

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

    • I’ve done giant data analysis (thousands upon thousands of numbers at a time) in MATLAB. That was numerical as all get-out. I dealt with strings not at all, for those 2.5 years.

      But web development is mostly strings, for sure.

      And while a large subset of librarians-who-code would want to do numeric data analysis, I still like it would be OK to do string manipulations first.

Leave a Reply

Your email address will not be published. Required fields are marked *