On May 1, 2020, at 11:19, Brandt Bucher <brandtbucher@gmail.com> wrote:
>
> I have pushed a first draft of PEP 618:
>
> https://www.python.org/dev/peps/pep-0618
The document says “… with nobody challenging the use of the word ‘strict’”, but people did challenge it, and even more people just called it “equal” instead of “strict” when arguing for it or +’ing it (which implies a preference even if there’s no argument there), and the only known prior art on this is more-itertools, which has a zip_equal function, not a zip_strict function.
I completely agree with this. I didn't bother replying to the original thread as other people had already mentioned my favourite idea which was to use something like
mode = "equal" | "shortest" | "longest"
with "shortest" as the default (avoiding causing any breakage with the existing function).
André Roberge
I think it misrepresents the arguments for a separate function and undersells the advantages—it basically just addresses the objections that are easiest to reject. I don’t want to rehash all of my arguments and those of a dozen other people, since they’re already in the thread, but let me just give one: A separate function can be used in third-party libraries immediately, as long as there’s an available backport (whether that’s more-iterools, or a trivial zip39 or whatever) that they can require; a flag can’t be used in libraries until they’re able to require Python 3.9 (unless they want to use a backport that monkey patches or shadows the builtin, but I doubt you’d suggest that, since you called it an antipattern elsewhere in the PEP).
It implies that infinite iterators are the only legitimate place where you’d ever want the existing shortest behavior.
Also, I don’t think anyone on the thread suggested the alternative of changing the behavior of zip _today_. Serhiy only suggested that we should leave the door open to doing so in the future, by having an enum-valued flag instead of a bool, or zip_shortest alongside zip_equal and zip_longest, or whatever. That allows people to explicitly say they want shortest when they want it, now—which might be beneficial even on its own terms. And if people end up usually using strict, and usually being explicit when they want shortest, then at that point it might be worth changing the default (or just not having one). So the argument against the alternative doesn’t really cover the actual thing suggested, but a different thing nobody wanted.
_______________________________________________
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/MHP3V2GFFBIDXVCY4T62TL4YRLGYGTGW/
Code of Conduct: http://python.org/psf/codeofconduct/