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]

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.