Steven: I understand that Alex said he thought that putting "strict" in as a flag would make it a bit more likely that people would use, and that he thinks that's a good thing, and you think that's a bad thing, but... Unless we were to make it the default behavior, very few people are going to be adding this flag "just in case". And the fact that you think that making it a flag will make it more likely that folks will use it is an argument for making it a flag. Unless you don't like the idea at all, and want it to be more obscure and hard to find. In any case, you seem to making the argument that a few of us are putting forward: yes, a flag on zip() is likely to get more use than a function in itertools. Thanks for the support :-) However, you also seem to be making the argument that this feature would do more harm than good. I disagree, but if that's what you think, then it shouldn't be added at all, so please make that case, rather than arguing for adding it, but making it harder to find. -CHB On Mon, May 4, 2020 at 6:54 PM Steven D'Aprano <steve@pearwood.info> wrote:
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-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/ZIQZLT... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython