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: ((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. 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. 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). 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. I do not think that could ever be an operator, but having a function that can help these kind of recursive comparisons would be great (I guess pytest uses/has such a function because it pretty nicely displays differences in sets, dictionaries and lists which are compared to each others in asserts). On Fri, 8 May 2020 at 16:23, Alex Hall <alex.moj...@gmail.com> wrote: > On Fri, May 8, 2020 at 5:11 PM Ethan Furman <et...@stoneleaf.us> wrote: > >> On 05/08/2020 07:50 AM, Alex Hall wrote: >> > On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote: >> >> On Fri, 8 May 2020 at 14:16, Steven D'Aprano <st...@pearwood.info >> <mailto:st...@pearwood.info>> wrote: >> >> >> >>> If you have ever written something like any of these: >> >>> >> >>> all(x==y for x,y in zip(a, b)) >> >> >> >> That looks like a zip call that could do with checking its input or >> strict=True! >> > >> > Steven mentioned that originally: >> >> >> >> (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.) >> > >> > But since you probably want these expressions to evaluate to false >> rather than raise an exception when the lengths are different, a strict zip >> is not appropriate. >> >> But if: >> >> short_sequence == long_sequence[:len(short_sequence)] >> >> then you'll get True. >> > > So you'd need to just check the lengths first. That was in Steven's older > code snippet, which I tried to quote and shows in my sent messages but not > now. Really hating this email quoting. > _______________________________________________ > 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/MSTSV76SAASQDW65JPXOUNJP7X6QLJZG/ > 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/GKYJLX7HJCZR3NZODMZ7BHIOLYXICVJF/ Code of Conduct: http://python.org/psf/codeofconduct/
