Tim Peters writes:
But hasn't it already been settled by experience? There is nothing unique about `first(set)` implicitly appealing to iteration order.
I'm not sure. I wouldn't think to use "first" on a set in my own code (and in others' code I'd consider it a code smell in many contexts, such as the example below). I rarely think of the order involved in iteration: I think of "for" as "for each". My focus is on a set of objects and what I do with each, not necessarily limited by the von Neumann architecture. I'm also bothered that "first(x); first(x)" has "first, second" semantics when x is an iterator and "first, first" semantics when x is not an iterator. I'd like to be able to generically recommend column_labels = first(table) for row in table: process(row, column_labels) because it's very elegant, but it's probably a bug if table is a list of tuples rather than an open file object. For me any use of "first" that doesn't throw away the rest of the iterable would be suspect, because changing a sequence to an iterator or the other way around is a frequent refactoring for me. It's still elegant if used carefully: itable = iter(table) column_labels = first(itable) for row in itable: process(row, column_labels) but then "first" is just a slightly inefficient way of spelling next.
I just don't see the potential for "new" bafflement if itertools.first works exactly the same way as itertools.anything_else _has_ worked, in this respect, all along.
Perhaps not. While I don't really trust a vote of the posters to this list on issues of potential for bafflement ;-), the fact that nobody else seems concerned is, uh, "suggestive".
Give users some credit.
I'm happy to do that at 21.6% per annum, but wouldn't it be more Pythonic to cut them some slack and keep them out of debt? Steve