On Sun, Apr 26, 2020 at 3:53 AM Kirill Balunov <kirillbalu...@gmail.com> wrote:
>
>
>
> 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.
>
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-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/A3TBZFJC27BXCFQWAD6DQU5ORWR42G7X/
Code of Conduct: http://python.org/psf/codeofconduct/
