2 ms·
I don't think that's right. You can always turn it into a greedy iterable (e.g. convert it to a list) if you need the certainty that you can modify the underlyi
by dmurray 6y ago
I don't think that's right. You can always turn it into a greedy iterable (e.g. convert it to a list) if you need the certainty that you can modify the underlying thing, while still reaping some performance benefits from the maybe-lazy iterator in the rest of your use cases. Assuming the iterator wasn't infinite, of course, but in that case you already knew it was lazy.
- joshuamorton 6y agoRight but you have to know the iterator was lazy to know that you need to convert it.
- hansvm 6y agoIs it really that arduous to have a high-level understanding of what the method you're calling does, at least at the level of knowing whether or not it returns the type of object you want and whether it takes ownership of its arguments? There's a separate question of whether the standard library should be inconsistent with itself, but it seems like a reasonable choice -- you can't efficiently use a json file without doing _something_ invasive to it like loading it all into ram, but a csv file isn't burdened the same way, and you probably don't want to be limited by available ram when all you need to do is enumerate a csv.
- joshuamorton 6y agoI'm not sure what you're arguing for. My point is that you cannot, in general, abstract over both lazy and eager iterators. There are irreconcilable differences in how they work (and how you have to treat them).