[hyperpape]

There just isn't that much to get wrong in pure for-each loops:

    def filter_broken(widgets):
        broken_widgets = []
        for widget in widgets:
            if widget.is_broken():
                broken_widgets.append(widget)
        return broken_widgets

The actual errors with loops and mutable objects come from complex nested loops, continues/breaks (multi-level ones especially!), extra boolean conditions, and sharing mutable objects between parts of the code base.

I think that overstating the supposed risks of for-loops doesn't help anything. The problem is not that you're going to mess up a simple for loop. It's the ways that your code doesn't compose well that are more problematic. Oh, and the verbosity sucks too.

[macintux]

Hm. Wouldn't your code reverse the order of the list?

Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

[hyperpape]

Append is a function that adds it to the end of the list. (I think my code is working Python, but I haven't actually run it).

Btw: I'd venture to guess that you're not a Python person, and that's why it's not obvious that it constructs the method in the same order. In imperative languages (where Python isn't the perfect example b/c it has filter and list comprehensions), you get so used to these loops that you don't have to worry about questions like that.

If you wanted a reversed list, you'd either name your function appropriately, or call reverse after you run the filter method. It's a little painful to do the first bit.

[macintux]

Yeah, sorry, got my mental model mixed up. I worry about reversing lists a lot since I deal with TCO so much.