On Fri, May 8, 2020 at 7:48 PM Steven D'Aprano <st...@pearwood.info> wrote:
> On Fri, May 08, 2020 at 01:00:48PM -0400, David Mertz wrote: > > > All the discussion following Steven's hypothetical .EQ. operator (yes, > not > > a possible spelling) just seems to drive home to me that what everyone > > wants is simply a function. > > > > Many different notions of "equivalence for a particular purpose" have > been > > mentioned. > > All of which are red herrings that are completely off-topic for this > proposal. This proposal has nothing to do with: > > > case_insensitive_eq(a, b) > > same_json_representation(a, b) > > allclose(a, b) # A version of this is in NumPy > > nan_ignoring_equality(a, b) > > and the only reason I deleted the "recursively equivalent" one is > because I don't know what it's supposed to mean. > > This proposal is a narrow one: its the same as list or tuple equality, > but duck-typed so that the container type doesn't matter. > > Do lists and tuples do case-insensitive comparisons? No. Then neither > does this proposal. > > Do lists and tuples do JSON-repr comparisons? No. Then neither does > this. > > Do lists and tuples do numeric "within some epsilon" isclose comparisons > (e.g. APL fuzzy equality)? Or ignore NANs? No to both of those. Then > neither does this proposal. > Would the proposal come with a new magic dunder method which can be overridden, or would it be like `is`?
_______________________________________________ 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/2FGESZSWJRBJOKWP3KF3UHSL7SBPMNU2/ Code of Conduct: http://python.org/psf/codeofconduct/
