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/