On Tue, Apr 28, 2020 at 02:46:35PM -0000, Brandt Bucher wrote:
Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP.
I cannot imagine why you were surprised about that. Did you already forget about the experience of dict union operators? :-) Aside from the Python-Ideas community being quite conservative about change at the best of times[1], this is a change with few obvious *concrete* use-cases that I have seen, a significant disagreement over the intent of the check (is it an assertion that should never be caught, or an exception that the caller may want to catch and recover from?), plus it has much opportunity for bikeshedding: - zip_strict or zip_equal or zip_exact or zip_same? - builtin or itertools? - function or recipe in itertools? - zip.method or function? - just use more-itertools? - deprecate zip and call it zip_shortest? - use a True/False flag or a string mode or an enumeration? - pass a callback function to zip? Unlike dict union operators, there is no long history of requests for this functionality (that I have seen). It wasn't added to itertools when zip_longest was added, not even as a recipe. And even more-itertools, which adds everything including the kitchen sink to their library, only added it within the last few weeks (give or take). So I don't think you should be surprised by the pushback on this.
With that in mind, I've started drafting one summarizing the discussion that took place here, and arguing for the addition of a boolean flag to the `zip` constructor. Antoine Pitrou has agreed to sponsor, and I've chatted with another core developer who shares my view that such a flag wouldn't violate Python's existing design philosophies.
Maybe you should chat with another core developer who *disagrees* with your view about such a flag? [1] Whether it is *excessively* conservative probably depends on how you feel about the change being proposed :-) -- Steven