Chris Angelico writes:
And ordered vs unordered is also a big difference. Should first() raise an error with sets because there's no real concept of "the first element"?
Probably not. I would prefer that it not be implemented at all, but if it is implemented, its behavior should respect the intuition of the majority of those who want it, which seems to me to be "a variant of next() that doesn't raise and returns None by default on an empty iterable."
With a list, first(x) will remain the same value even if you add more to the end of the list, but unrelated mutations to a set might change which element is "first".
Worse, running the same program again with the *same* set can change which element is first, I believe. Also, the elements of the set might have a natural (pre)order, which first() won't respect. I'm not sure if this last is a real problem, given that sequences have the same issue (the sequence's order differs from the natural order). However, to me the fact that a set's iteration order is implicit while a sequence's is explicit suggests it might in some contexts.
Does that mean that first() and next() are undefined for sets?
first() is undefined. next() is defined by reference to iterating over the set (that's why I don't have a problem with iterating over a set).
No. We just accept that there are these differences.
Well, if first() is implemented, we'll have to accept it. It's not clear to me that we should.