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 email@example.com wrote:
On 6 October 2016 at 14:45, Filipp Bakanov firstname.lastname@example.org wrote:
For now there are many usefull builtin functions like "any", "all", etc.
like to propose a new builtin function "equal". It should accept
and return True if all items in iterable are the same or iterable is
That's quite popular problem, there is a discussion of how to perform it
- 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.
Paul _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/