On Mon, May 04, 2020 at 09:20:28PM +0200, Alex Hall wrote: > > Seriously, if some object defines a weird `__eq__` then half the > > standard library, including builtins, stops working "correctly". See for > > example the behaviour of float NANs in lists. > > > > My care factor for this is negligible, until such time that it is proven > > to be an issue for real objects in real code. Until then, YAGNI. > > Here is an example:
Alex, I understand the point you are trying to make, and I got the reference to numpy the first time you referenced it. I just don't care about it. As far as I am concerned, numpy array's equality behaviour is even more broken than float NANs, and it's not the stdlib's responsibility to guarantee "correctness" (for some definition thereof) if you use broken classes in your data -- especially not for something of marginal value as "zip_strict", as you admitted yourself: "The problem is that no one really *needs* this check. You *can* do without it." Right. So it's a "nice-to-have", not an essential function, and it can go into intertools. The itertools implementer can decide for themselves whether they care to provide a C accelerated version as well as a Python version from Day 1, or even whether a recipe is enough. My point here is entirely that we shouldn't feel ourselves forced into *premptively* providing a C version, let alone making this a builtin, just because `x in y` breaks if one of the elements of y is a numpy array. numpy itself doesn't need this function, they do their own length checks. -- 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/ZIQZLTKRMGSCELSWZ2EQCW24CZ44B4MG/ Code of Conduct: http://python.org/psf/codeofconduct/
