3 ms·
As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...
by fpgeek 10y ago
As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...
- hyperpape 10y agoThere 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 10y agoHm. 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 10y agoAppend 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 10y agoYeah, sorry, got my mental model mixed up. I worry about reversing lists a lot since I deal with TCO so much.