On Fri, May 1, 2020 at 5:55 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
> On May 1, 2020, at 11:19, Brandt Bucher <brandtbuc...@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-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/MHP3V2GFFBIDXVCY4T62TL4YRLGYGTGW/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/UJVFHWEVJ3MOJRSZJLFLU73L3WWFI2YX/ Code of Conduct: http://python.org/psf/codeofconduct/
