On Sun, May 17, 2020 at 6:14 AM Rhodri James <rho...@kynesim.co.uk> wrote:
> On 16/05/2020 17:14, Guido van Rossum wrote: > > On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano<st...@pearwood.info> > wrote: > > > >>> * zip(strict=True) +1 > >>> * zip(mode='strict') -0 > >>> * itertools.zip_strict() -0.5 > >>> * zip.strict() -1 (but really, I'd like to make this -1e10) > >> I spent a significant amount of time and mental energy explaining in > >> detail why a boolean flag is a poor API and is objectively the wrong > >> interface here. This is not just a matter of personal taste: there are > >> reasons why a flag is wrong here. > >> > > Clearly it is not the objective truth, otherwise you would have an easier > > way convincing everyone.:-) > > OK, let's put some numbers on this. We only have 9 votes in, but aside > from Brandt (whose position is fairly obvious from the PEP) that > includes most of the people who have expressed strong opinions one way > or another. Ignoring the nuances of +/-0, we end up with: > > itertools.zip_strict(): +5.5 > zip(strict=True): +1 > zip.strict(): -1.9 > zip(mode='strict'): -4 > > (I bet Steven is wishing he hadn't been so generous to the "strict=True" > option now :-) > > Now I'm not fool enough to mistake a public vote for an objective truth > (::looks pointedly around world politics::) but there are some > interesting conclusions here. > > 1) Nobody (aside from Steven) wants a "mode" keyword. I suspect this is > because both of the two main camps (zip(strict=True) and zip_strict()) > have solid reasons against it; for the first, it's an unnecessary > distraction, and for the second the existence of zip_longest() argues > against it. > > 2) People don't hate zip.strict() as much as I had expected. > > 3) The PEP needs to come up with an actual argument against > itertools.zip_strict(). The current dismissal ain't going to cut it. > > Let me attempt a metaphor, which won't be perfect but may help: The safety one gets from strictness is a bit like driving a car wearing a seat belt. It is not fundamentally different from driving a car without a seat belt, and in most cases you hope the seat belt will not come into play. But it is a precaution that is worth taking in *most* circumstances (not all, e.g. for infants a standard seat belt won't work). The built-in approaches (whether spelled as zip(strict=True), or zip.strict(), or a new zip_strict() builtin) make it really easy for everybody to take the safety precaution where it is appropriate. By contrast, putting it in itertools where it has to be imported is like requiring someone to rent seat belts in order to use them in their car. Some safety-conscious folks will go to the trouble; others won't. itertools.zip_longest() is sort of a power tool for specialized situations—in our analogy, say, a pickup truck that has to be rented. Yes, with some work it *can* be used to emulate strict-zip, but most people won't think of it that way; they will think of it as something you only need in special situations. Is there some logic to the objection that it is weird to have two forms of zip (or one form with two variants) that are built in, and a third that is in itertools? Sure. But this seems to me a clear case of practicality beats purity. As an extremely common use case of zip (for many people), it will be most useful if it is built in. Nathan > > -- > Rhodri James *-* Kynesim Ltd > _______________________________________________ > 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/N4QLALMOLUWHYFSLKEONJ7UYF2YBQY4R/ > 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/3IPR5FWN7CZUETIPCSACXXOK4BK6TNRF/ Code of Conduct: http://python.org/psf/codeofconduct/
