`itertools.all_equal`

[hypernova]

@Stefan2

Because that’s your code and when iterable is a list, then both the iterable[1:] and the iterable[:-1] make a copy of the entire list minus one element, both taking linear space.

Ah, I see why you are confused. You did not read the full question.

Near the bottom of the post:

@hypernova

I’m not totally sure exactly how it should be done. If a map_pairwise was introduced, then why not higher-order versions which apply functions consisting of 3 arguments, or more?

There was confusion about this on the linked post. I later clarified:

@hypernova

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.

Part of the problem was the post was moved and merged into some other post which had nothing to do with my proposal and was a discussion on documentation.

@hypernova

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.

To clarify the point so that everyone can understand:

• My original proposal was to add a version of map which works with binary operators. map_binary or some other name.
• Please don’t misunderstand: map works with binary operators if you provide two iterables. This is not the same problem. I am proposing something which takes a single iterable.
• I suggested this as an intermediate step to solving the all_equal problem.
• The current suggestions to implement all_equal are either slow, or they use some form of prematurely optimized “hack” resulting in unreadable code. (The point of Python is it is supposed to be less complicated than something like C++, not more.)
• I suggested adding this because it is more general than implementing all_equal directly.
• However it comes with disadvantages: One is that although binary_map is obvious, it cannot be extended further in an obvious way. How would you implement a version for a function of three arguments? It isn’t clear how they should align over the input elements from the iterable. Should you advance the iterable by 1 step each time or 2? In the first case you have something which overlaps elements twice, in the second case you only overlap a single element. The fact that this is complicated to explain perhaps suggests the idea is already too complicated. It’s also not obvious what other usecases you might have. For example, if you want to add all elements with operator.add there is already a sum function. Similarly, there is a product function which you could also implement with binary_map plus operator.mul. Then for other binary operators, it’s not clear what the result of mapping operator.sub or operator.div might be? Hopefully it’s clear what I’m describing here, but I suspect it isn’t. The fact that it is much easier to explain with a diagram suggests that this is probably not a good idea.
• I then went away to attempt to implement such all_equal directly, without map_binary. I did this because it became obvious to me that all_equal would be easier to implement directly instead.
• The difference in performance is a factor of 2 for iterables containing objects which have simple implementations of __eq__.
• It makes no difference on a list of 1 strings where the length of the string is infinite, because most of the runtime is spent evaluating __eq__ and not in the iterating part.