It is a real problem. People are used to write `seq == [1, 2, 3]` and it passes unnoticed (even with type checkers) that if seq changes to e.g. a tuple, it will cause subtle bugs. It is inconvenient to write `len(seq) == 3 and seq == [1, 2, 3]` and people often don't notice the need to write it.

(I'd like to note that it makes sense for this operation to be written as 

    *iter1 == *lst

although it requires a significant change to the language, so a Sequence.equal function makes sense)


On Thu, Oct 6, 2016 at 5:02 PM Paul Moore <> wrote:
On 6 October 2016 at 14:45, Filipp Bakanov <> wrote:
> For now there are many usefull builtin functions like "any", "all", etc. I'd
> like to propose a new builtin function "equal". It should accept iterable,
> and return True if all items in iterable are the same or iterable is emty.
> That's quite popular problem, there is a discussion of how to perform it on
> stackoverflow
> (
> - all suggestions are either slow or not very elegant.
> What do you think about it?

It's not a problem I've needed to solve often, if at all (in
real-world code). But even if we assume it is worth having as a
builtin, what would you propose as the implementation? The
stackoverflow discussion highlights a lot of approaches, all with
their own trade-offs. One problem with a builtin is that it would have
to work on all iterables, which is likely to preclude a number of the
faster solutions (which rely on the argument being an actual list).

It's an interesting optimisation problem, and the discussion gives
some great insight into how to micro-optimise an operation like this,
but I'd question whether it needs to be a language/stdlib feature.

Python-ideas mailing list
Code of Conduct: