On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote: > Imagine someone that uses zip() in code that works for a while, and then > discovers a bug triggered by unequal length inputs. > > If it’s a flag, they look at the zip docstring, and find the flag, and > their problem is solved.
Their problem is not solved. All they have is an exception. Now what are they going to do with it? This is why I am still unconvinced that this functionality is anywhere near as useful as the proponents seem to think. Brandt has found one good example of a parsing bug in the ast library, but if he has shown how this zip_strict function will solve the bug, I haven't seen it. In any case, even giving Brandt the benefit of the doubt that this will solve the ast bug, its hard for me to generalise from that. If I'm expecting equal length inputs, and don't get them, what am I supposed to do with the exception as the consumer of the inputs? As the consumer of the inputs, I can pass the buck to the producer, make it their responsibility, and merely promise to truncate the inputs if they're not the same length. Otherwise, what do I do once I've caught the exception? The most common use for this I have seen in the discussion is: "I have generated two inputs which I expect are equal, and I'd like to be notified if they aren't" which to me is an assertion about program correctness. So this ought to be an assert that gets disabled under -O, not a raise that the caller might catch. So this suggests *two* new functions: - zip_equal for Brandt's parsing bug use-case, guaranteed to raise - zip_assert_equal for the more common use case of checking program correctness, and disabled under -O > Is it’s in itertools, they have to think to look there. And this is a problem, why? Should *everything* be a builtin? Heaven forbid that somebody has to read the docs and learn about modules, let's have one giant global namespace with everything in it! Because that's good for the beginners! (Not.) -- 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/ODVT4PXERBBFAHBAMJPYF67DFRZULTKS/ Code of Conduct: http://python.org/psf/codeofconduct/
