On Sun, Apr 26, 2020 at 3:53 AM Kirill Balunov <kirillbalunov@gmail.com> wrote:
>
>
>
> On Sat, Apr 25, 2020 at 8:11 PM David Mertz <mertz@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.
>

Separate functions mean you can easily and simply make a per-module decision:

from itertools import zip_strict as zip

Tada! Now this module treats zip as strict mode. To do that with a
mode-switch parameter, you have to put the parameter on every single
call to zip (and if you forget one, it's not obvious), or create a
wrapper function.

ChrisA
_______________________________________________
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/A3TBZFJC27BXCFQWAD6DQU5ORWR42G7X/
Code of Conduct: http://python.org/psf/codeofconduct/