# \`itertools.all\_equal\` **URL:** \ **Category:** Ideas\ **Created:** [March 3, 2024, 12:04am UTC](https://discuss.python.org/t/itertools-all-equal/47434 "2024-03-03T00:04:19Z")\ **Posts on this page:** 1\ **Showing post:** 20
**Author:** ![hypernova](https://avatars.discourse-cdn.com/v4/letter/h/85f322/32.png) [@hypernova](https://discuss.python.org/u/hypernova)\ **Post date:** [March 8, 2024, 8:09am UTC](https://discuss.python.org/t/itertools-all-equal/47434/20 "2024-03-08T08:09:46Z")
> [@Stefan2](#): > > Because that’s [your code](https://discuss.python.org/t/a-high-performance-solution-to-the-are-all-elements-of-an-iterable-equal-problem/46848) 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: > [@A high-performance solution to the "are all elements of an iterable equal" problem](https://discuss.python.org/t/a-high-performance-solution-to-the-are-all-elements-of-an-iterable-equal-problem/46848/1): > > 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: > [@A high-performance solution to the "are all elements of an iterable equal" problem](https://discuss.python.org/t/a-high-performance-solution-to-the-are-all-elements-of-an-iterable-equal-problem/46848/8): > > Just to say I think you missed the point here. I am not suggesting > > ```python > 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. > [@A high-performance solution to the "are all elements of an iterable equal" problem](https://discuss.python.org/t/a-high-performance-solution-to-the-are-all-elements-of-an-iterable-equal-problem/46848/8): > > 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. --- _[View the full topic](https://discuss.python.org/t/itertools-all-equal/47434)._