Just to say I think you missed the point here. I am not suggesting
map(operator.eq, iterable[1:], iterable[:-1])
is an example of good code - far from it in fact.
By the way, was my post moved or something? I am not familiar with this kind of forum, but it looks like the original post made has been attached to some longer running thread from Feb 20th.
Raymond, I have read through your answer and would suggest that the existence of both the twitter thread and your answer indicate a missing feature from the Python ecosystem as it currently stands. Allow me to explain -
(This is not a criticism of your work to collate these things by the way.)
If we look at each of these options, ask yourself, which of them would you be happy to see show up in a code review if it were sent to you?
I would suggest the answer is none. In each case there is an argument to be made that the solution is either hard to understand or at the very least not immediately obvious what it does (and therefore requires thinking about - which is never a good thing). OR the runtime is likely to be slow. Many of the examples do not have an early termination condition.
A good Python code is obvious and self-explanatory.
The solution I used is also unsatisfactory for the same reasons - I already provided criticism of it as did someone else on this thread.
Herein lies the problem: None of the proposed answers in the entire Stack Overflow thread actually say literally what they are doing.
Let me explain -
What did we want to do?
- We wanted to test to see if all objects returned by iterating over an iterator have the same value according to
operator.eq
.
Which of the proposed solution says this?
- None of them.
Let’s take my example, and criticize it:
What does the following code say that it does?
all(map(operator.eq, iterable[1:], iterable[:-1]))
It says this:
- create an iterator from the second element of the input to the last element of the input
- and create another iterator from the first element of the input to one element before the last element of the input
- and apply
operator.eq
to the values yielded by these iterators - and test if all the resulting values returned by
operator.eq
areTrue
Is that anything like our original problem statement of “are all elements equal”? Not really.
And this is the point: The code I have written does not clearly say what it does.
This is why I think we need some other solution, perhaps in the form of a map_binary
feature. (Or perhaps something else.)