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