On Sat, Apr 25, 2020 at 8:11 PM David Mertz <me...@gnosis.cx> wrote:

> I have no objection to adding a zip_strict() or zip_exact() to itertools.
> I am used to the current behavior, and am apparently in minority in not
> usually assuming common length iterators. Say +0 on a new function.
>
> But I'm definitely -1 on adding a mode switch to the built-in. This is not
> the way Python is usually done. zip_longest() is a clear example, but so is
> the recent cut_suffix (or whatever final spelling was chosen). Some folks
> wanted a mode switch on .rstrip(), and that was appropriately rejected.
>
>
Python uses such an approach (separate functions) because there are real
flaws in the mode switching approach? Or just historically? As for me the
mode switching approach in the current situation looks reasonable, because
the question is how boundary conditions should be treated. I still prefer
three cases switch like `zip(..., mode=('equal' | 'shortest' | 'longest'))`...
but also ok with `strict=True` variant.

Also I don't think that comparison with .rstrip() discussion is fair -  because
in that case, it was proposed to switch two completely different approaches
(to treat as string vs to treat as set of chars) which is too much for just
a switch thorugh argument. While in zip case it is just how boundaries are
treated.


> If zip_strict() is genuinely what you want to do, an import from stdlib is
> not much effort to get it. My belief is that usually people who think they
> want this actually want zip_longest(), but that's up to them.
>
> _______________________________________________
> 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/DZZ7I3PEVYB2LW6Y2ECSQRUUTYEB3D7O/
> 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/3T3VZESKNUNJZBYXXGIQSXTWZBZ3MX2W/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to