On Fri, May 08, 2020 at 04:51:04PM +0100, Henk-Jaap Wagenaar wrote:
> FYI, it does show in my version on gmail and on the mailman version.
> <https://mail.python.org/archives/list/python-ideas@python.org/message/WJKNLRIRYT7EFX7ZH2OHXYI772XD5R3J/>
>
> BTW, I think strings do showcase some problems with this idea, .EQ. (as
> defined by Steven) is not recursive, which I think will be
> unworkable/unhelpful:
The sample implementation I gave was explicitly described as "very
roughly". In no way was it intended to be the reference implementation.
It was intended to begin the process of deciding on the semantics, not
end it.
> ((0, 1), (1, 2)) and ([0, 1], [1, 2]) are not equal under the new operator
> (or new behaviour of == depending as per the OP) which I think goes
> completely against the idea in my book.
(1) Ahmed has already accepted that changing `==` is not suitable, so
please let us all stop beating that dead horse! `==` is not going to
change.
(2) The intention is for
((0, 1), [1, 2], 'ab') .EQ. [[0, 1], (1, 2), ['a', 'b']]
to return True, as well as similar examples. On the other hand, this is
not just a "flattening equality" operator, this would return False:
((0, 1), (1, 2)) .EQ. ((0,), (1, 2, 3))
since (0, 1) and (0,) have different lengths.
> If it were (replace x==y with x == y || x .EQ. y with appropriate error
> handling), strings would not work as expected (I would say), e.g.:
>
> [["f"], "o", "o"] .EQ. "foo"
>
> because a an element of a string is also a string.
Why would that not work?
* ["f"] .EQ. "f" is true since they both have length 1 and their
zeroth elements are equal;
* "o" .EQ. "o" is true;
* "o" .EQ. "o" is still true the second time :-)
* so the whole thing is true.
> Worse though, I guess
> any equal length string that are not equal:
>
> "foo" .EQ. "bar"
>
> would crash as it would keep recursing (i.e. string would have to be
> special cased).
Yes. Is that a problem? As I already pointed out, it will also need to
handle cycles. For example:
a = [1, 2]
a.append(a)
b = (1, 2, [1, 2, a])
and I would expect that a .EQ. b should be True:
len(a) == len(b)
a[0] == b[0] # 1 == 1
a[1] == b[1] # 2 == 2
a[2] == b[2] # a == a
so that's perfectly well-defined.
> What I do sometimes use/want (more often for casual coding/debugging, not
> real coding) is something that compares two objects created from JSON/can
> be made into JSON whether they are the same, sometimes wanting to ignore
> certain fields or tell you what the difference is.
Feel free to propose that as a separate issue.
--
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/22I65SJIHWNFQYDPTVJ4P7F4TB2V2KHK/
Code of Conduct: http://python.org/psf/codeofconduct/
