In Which We Learn to Code

[writerkit]

Ever have those days where you are absolutely certain you have somehow messed up the process despite getting something that produces the answer the book asks for?

I am learning about lists and loops in my Python book. Logically this specific exercise is clearly an extension of the whole "x = x + 1" conceptual problem which I had to get Mathfriend to explain to me in very small words but have a good handle on now.

You are given a list: xs = [12, 10, 32, 3, 66, 17, 42, 99, 20]

The assignment is to find the product of the list using a loop.

This works:

total = int(1)
for xs in [12, 10, 32, 3, 66, 17, 42, 99, 20]:
    total = int(total * xs)

print(total)

It produces the desired result. If you omit setting total to 1 at the beginning it complains about total being undefined farther down, which I get. It depends on itself; it needs to start at something. And setting it to start at 1 doesn't mess with the end result. (The previous exercise was addition and it started at zero.)

I cannot shake the feeling I am getting some part of this wrong in some way, possibly in this being the wrong approach to it, but I can't figure out another possible one with the terms the book has described so far. Especially when the addition exercise did explicitly say "set it to zero to start." I just feel like a more elegant way to do it should exist.

(Also welcome to the posts where I complain about my coding lessons. Particularly in self-teaching I find it easier to actually sit down to do things if I'm writing up a Dreamwidth post about them, so you'll be getting some chronicling of my Adventures in Code coming up.)

Comments

[squirrelitude]

OK, cool! So, here are a couple things that jump out at me as unidiomatic. They're not *wrong*, mind you, but a lot of programming is about communicating intent to other programmers (including you-six-months-from-now). People don't really read code so much as skim it, so using common idioms can really help.

First, you should be able to drop those int calls without changing the effect of the code. That functions converts non-integer numbers to integers, or reads a numeric string (such as "476") as an integer. Both of the expressions 1 and total * xs are already going to be integers.

Second, when I see the variable xs I would generally assume it's a collection of things. One x, multiple xs. Just a naming convention. If I define a function that takes a list of integers or non-descript things, I'll probably write xs for the parameter name. But if I have a single such thing, I'll name it x.

So the main part of your code might look like this instead:

total = 1
for x in [12, 10, 32, 3, 66, 17, 42, 99, 20]:
    total = total * x

A non-exactly-coding thing is that I might call it "product" rather than "total". My first thought when reading the code was that you were adding things together, and then I had to revise my understanding when I saw the multiplication.

Again, your code is correct! But these are things you could change that would make it easier for me to read. (Of course, opinions may vary on things like naming.)

[squirrelitude]

I'll also mention that you could consider changing total = total * x to total *= x -- it means essentially the same thing, and would be how I would write it since it's nicely terse and expresses the concept of "folding in a multiplication" in a way I can understand at a glance, without having to notice that "total" is on both sides of the "=". (You're not just assigning the result of any ol' multiplication to total, but a multiplication that builds on total.) But... I also remember it was confusing to me when I first encountered that syntax. And not all proficient programmers even like that syntax. I only mention it because you'll likely see that syntax sooner or later, and probably already have in cases like foo += 1.

[elusiveat]

nicely terse

I'm surprised to see this phrase, as it feels like a bit of an oxymoron.

I also use += and *= syntax myself, but I always feel a bit icky doing it because it feels *so* idiomatic. Like, if x=x+1 is hard for non-programmers, how is x+=1 an improvement?

Or maybe I only feel this way because I learned Java first, and C later. I dunno : \

[squirrelitude]

I do value terseness, although not when it impedes understanding, or loses explicitness. I'll often assign intermediate results to variables just so they get names that communicate to the reader.

I think a good bit of this habit comes from having programmed in Clojure for 10 years, where that's the predominant aesthetic and I could just write (println (apply * [12 10 32 3 66 17 42 99 20])) and be done with it. To a Clojure programmer it's quite clear what that does, and writing anything longer would actually be more confusing -- because the reader would be trying to model it in their head as something more complicated, to go along with the longer code.

[elusiveat]

I could just write (println (apply * [12 10 32 3 66 17 42 99 20])) and be done with it.

I think I get what you're saying. On the other hand, isn't it also true in this case that the above is also the most elegant way of writing the code?

[squirrelitude]

Terse and elegant are the same thing there, yeah.