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/ZIQZLTKRMGSCELSWZ2EQCW24CZ44B4MG/
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