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
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-leave@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/JP3BXZ... Code of Conduct: http://python.org/psf/codeofconduct/