3 ms·

What would you do in this case? The student has never seen a tuple, or iterable unpacking of any form. Would you just show them `for index, word in enumerate(w

What would you do in this case? The student has never seen a tuple, or iterable unpacking of any form. Would you just show them `for index, word in enumerate(words)` and tell them not to worry about what that means? Quite shortly after this, I ask them to essentially do `zip_longest`. Given two string variables: string1 = "Goodbye" string2 = "World" output: G W o o o r d l b d y e Here's what I expect their solution to look like: length1 = len(string1) length2 = len(string2) if length1 > length2: # one could use max, but I don't expect them to length = length1 else: length = length2 for i in range(length): if i < len(string1): char1 = string1[i] else: char1 = ' ' if i < len(string2): char2 = string2[i] else: char2 = ' ' print(char1 + ' ' + char2) That's not something that can nicely be solved with enumerate. Do you think this exercise is bad because they should just use zip_longest instead?

travisjungroth 6y ago
I'd split the problem into two. You're talking about these problems like they're fixed, but they're not. This is your project. I'd teach index access and number generation separately, with small incrementing variations. Then I'd show iteration, then enumeration (maybe after tuple unpacking). When you combine two concepts it doesn't create just a combination. It creates one or more new concepts. Those new concepts have their own idioms and they should be taught properly. Combining looping over numbers and index access creates two new concepts: looping over items and looping over items with their index. Both of those things have their own idiom in Python and your solution shows neither. I think telling someone not to worry about the details of how something works because you'll get back to it later is way better than showing them the wrong thing and then correcting it. One is a promise kept, the other a promise broken. In my opinion, nailing this kind of stuff is like half of the value of the project you're doing. You need to lean way in on it and get it right. My take is right now you're thinking backwards from the position of someone who knows how to code. You need to think forward like someone who doesn't, at least more often. A student isn't going to be motivated to learn a, b = c by learning return a, b first because they won't know that second concept exists! In short, if your students aren't ready to use enumerate or zip_longest, don't hand them problems that call for enumerate or zip_longest.
- zbentley 6y ago
  > I think telling someone not to worry about the details of how something works because you'll get back to it later is way better than showing them the wrong thing and then correcting it. One is a promise kept, the other a promise broken. I'm not sure I'd say teaching someone to do something by hand for which they could use an existing function is "wrong". There's huge pedagogical value in knowing how powerful tools you didn't make work. Going bottom-up is a very effective way to do that (just ask the lisp folks), and a culmination of "nice job, you've implemented something so useful that it mirrors what the language designers/library authors did as well, here's how to use their version to save time in the future" is far from a broken promise.
  - travisjungroth 6y ago
    > I'm not sure I'd say teaching someone to do something by hand for which they could use an existing function is "wrong". I didn't say it was wrong the wrong way to teach. I said the code was wrong. Like, if I removed myself from teaching and I just saw that in a PR, I'd definitely suggest they use enumerate instead. I'm a huge fan of reimplementing built in functions as a way to learn. I'm learning Clojure right now (like I stopped to write this comment) and I do it all the time. But, I know I'm doing it. The other thing that's fine is building up to the abstraction. "Let's get the index, now the item. Okay, there's a better way to do this". But you have to do it immediately. I'm just not a fan of showing someone something, letting it sink in, and then having to go back and correct it. And while I hope my arguments stand on their own, and I certainly could be wrong, I'm at least not speaking out of complete inexperience. I've spent a decent amount of time teaching people to code, juggle, work at rope courses, and fly airplanes.
    - alexmojaki 6y ago
      Do you get reply notifications?
      - travisjungroth 6y ago
        No, I just check my comments.

travisjungroth 6y ago

I'd split the problem into two. You're talking about these problems like they're fixed, but they're not. This is your project. I'd teach index access and number generation separately, with small incrementing variations. Then I'd show iteration, then enumeration (maybe after tuple unpacking). When you combine two concepts it doesn't create just a combination. It creates one or more new concepts. Those new concepts have their own idioms and they should be taught properly. Combining looping over numbers and index access creates two new concepts: looping over items and looping over items with their index. Both of those things have their own idiom in Python and your solution shows neither. I think telling someone not to worry about the details of how something works because you'll get back to it later is way better than showing them the wrong thing and then correcting it. One is a promise kept, the other a promise broken. In my opinion, nailing this kind of stuff is like half of the value of the project you're doing. You need to lean way in on it and get it right. My take is right now you're thinking backwards from the position of someone who knows how to code. You need to think forward like someone who doesn't, at least more often. A student isn't going to be motivated to learn a, b = c by learning return a, b first because they won't know that second concept exists! In short, if your students aren't ready to use enumerate or zip_longest, don't hand them problems that call for enumerate or zip_longest.

zbentley 6y ago
> I think telling someone not to worry about the details of how something works because you'll get back to it later is way better than showing them the wrong thing and then correcting it. One is a promise kept, the other a promise broken. I'm not sure I'd say teaching someone to do something by hand for which they could use an existing function is "wrong". There's huge pedagogical value in knowing how powerful tools you didn't make work. Going bottom-up is a very effective way to do that (just ask the lisp folks), and a culmination of "nice job, you've implemented something so useful that it mirrors what the language designers/library authors did as well, here's how to use their version to save time in the future" is far from a broken promise.
- travisjungroth 6y ago
  > I'm not sure I'd say teaching someone to do something by hand for which they could use an existing function is "wrong". I didn't say it was wrong the wrong way to teach. I said the code was wrong. Like, if I removed myself from teaching and I just saw that in a PR, I'd definitely suggest they use enumerate instead. I'm a huge fan of reimplementing built in functions as a way to learn. I'm learning Clojure right now (like I stopped to write this comment) and I do it all the time. But, I know I'm doing it. The other thing that's fine is building up to the abstraction. "Let's get the index, now the item. Okay, there's a better way to do this". But you have to do it immediately. I'm just not a fan of showing someone something, letting it sink in, and then having to go back and correct it. And while I hope my arguments stand on their own, and I certainly could be wrong, I'm at least not speaking out of complete inexperience. I've spent a decent amount of time teaching people to code, juggle, work at rope courses, and fly airplanes.
  - alexmojaki 6y ago
    Do you get reply notifications?
    - travisjungroth 6y ago
      No, I just check my comments.