But you also can always make such a switch with functools.partial.

-gdg

On Sat, Apr 25, 2020 at 8:59 PM Chris Angelico <ros...@gmail.com> wrote:

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

Reply via email to