On Thu, May 07, 2020 at 03:43:23PM +0200, Dominik Vilsmeier wrote: > >We could define this .EQ. operate as *sequence equality*, defined very > >roughly as: > > > > def .EQ. (a, b): > > return len(a) == len(b) and all(x==y for x, y in zip(a, b)) > > > But why do we even need a new operator when this simple function does > the job (at least for sized iterables)?
Maybe it doesn't need to be an operator, but operators do have a big advantage over functions: http://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html On the other hand we only have a limited number of short symbols available in ASCII, and using words as operators reduces that benefit. > How common is it to compare two objects where you cannot determine > whether one or the other is a tuple or a list already from the > surrounding context? In the end these objects must come from somewhere > and usually functions declare either list or tuple as their return type. Never, because we can always determine whether something is a list or tuple by inspecting it with type() or isinstance(). But that's missing the point! I don't care and don't want to know if it is a tuple or list, I only care if it quacks like a sequence of some kind. The use-case for this is for when you want to compare elements without regard to the type of the container they are in. This is a duck-typing sequence element-by-element equality test. If you have ever written something like any of these: list(a) == list(b) tuple(a) == b ''.join(chars) == mystring all(x==y for x,y in zip(a, b)) then this proposed operator might be just what you need. -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2375P7QI66QZ4VCL7SJRUFU3AXOMVIJZ/ Code of Conduct: http://python.org/psf/codeofconduct/
