Why use "." which has clear syntax problems? This can already be done in current Python (this was linked to in a previous thread about something else) using a generic solution if you change the syntax:
https://pypi.org/project/infix/ You could write it as |EQ|, ^EQ^, ... and have it in its own Pypi package. Not sure what IDEs think of this package, they probably hate it... On Thu, 7 May 2020 at 10:18, Steven D'Aprano <st...@pearwood.info> wrote: > On Sat, May 02, 2020 at 05:12:58AM -0000, Ahmed Amr wrote: > > > Currently, when comparing a list of items to an array of the same > > items for equality (==) it returns False, I'm thinking that it would > > make sense to return True in that context, as we're comparing item > > values and we have the same way of indexing both collections, so we > > can compare item values. > > I'm going to throw out a wild idea (actually not that wild :-) that I'm > sure people will hate for reasons I shall mention afterwards. > > Perhaps we ought to add a second "equals" operator? To avoid > bikeshedding over syntax, I'm initially going to use the ancient 1960s > Fortran syntax and spell it `.EQ.`. > > (For the avoidance of doubt, I know that syntax will not work in Python > because it will be ambiguous. That's why I picked it -- it's syntax that > we can all agree won't work, so we can concentrate on the semantics not > the spelling.) > > 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)) > > (Aside: if we go down this track, this could be a justification for > zip_strict to be a builtin; see the current thread(s) on having a > version of zip which strictly requires its input to be equal length.) > > The precise details of the operator are not yet clear to me, for > instance, should it support iterators or just Sized iterables? But at > the very least, it would support the original request: > > [1, 2, 3] .EQ. (1, 2, 3) > # returns True > > > The obvious operator for this would be `===` but of course that will > lead to an immediate and visceral reaction "Argghhh, no, Javascript, do > not want!!!" :-) > > Another obvious operator would be a new keyword `eq` but that would > break any code using that as a variable. > > But apart from the minor inconveniences that: > > - I don't know what this should do in detail, only vaguely; > - and I have no idea what syntax it should have > > what do people think of this idea? > > > -- > 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/JP3BXZLQRQYHGSB4KOX2K5TLP6A6PLR2/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/LVVAQQYY7SYM7M5MGER5DVRVQ2NTMH3O/ Code of Conduct: http://python.org/psf/codeofconduct/
