I'm definitely in camp map/filter/fold, but if you instantiate a list/accumulator, fill/operate on it inside the loop, then consume it, you're essentially writing pure code. The fact that you're doing it on top of mutable foundations doesn't matter (at that scale).

The trouble is that safe mutation and dangerous mutation look very similar. It's possible to write a function that performs safe, locally encapsulated mutation, sure - but it's much harder for a reader to confirm those properties in code review or when debugging compared to just seeing that the code doesn't do any mutation at all.

As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...

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.

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.

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.

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