> but the main > benefit is, again, being able to get the iterated values which were > silently swallowed by zip when the iteration stopped.
I don't think the call back idea is terrible, however, it doesn't really seem to have a usecase that isn't covered by zip_longest with a sentinel. Now as discussed in the main thread zip strict could also be handled by zip_longest with a sentinel. However, zip strict is an incredibly common usecase. There is no evidence that recovering the consumed elements is. > also: I don't like booleans. they're not extensible, unless you consider > None. you either get it right the first time, add a new boolean argument > later, or use enum.Flag from the beginning. this callback-based API > sidesteps all these issues While in theory I very much support the use of enums for flags, they have serious performance problems which makes their use inadvisable in the standard lib let alone a builtin. https://bugs.python.org/issue39102 https://bugs.python.org/issue38659 On Fri, May 1, 2020 at 1:20 PM Soni L. <fakedme...@gmail.com> wrote: > > > On 2020-05-01 4:43 p.m., Chris Angelico wrote: > > On Sat, May 2, 2020 at 5:21 AM Soni L. <fakedme...@gmail.com> wrote: > > > > > > > > > > > > On 2020-05-01 3:41 p.m., Chris Angelico wrote: > > > > On Sat, May 2, 2020 at 4:38 AM Soni L. <fakedme...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > > > > > I have pushed a first draft of PEP 618: > > > > > > > > > > > > https://www.python.org/dev/peps/pep-0618 > > > > > > > > > > > > Please let me know what you think – I'd love to hear any *new* > feedback that hasn't yet been addressed in the PEP! > > > > > > > > > > What about using an optional kwarg for a handler for mismatched > lengths? > > > > > I made a post about it on the other thread and it's not addressed > in the > > > > > PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka > > > > > zip(strict=True)) and zip_longest, it's not stringly-typed, and > it's > > > > > user-extensible. Something along the lines of zip(foo, bar, baz, > > > > > and_then=lambda consumed_items, iters: ...). > > > > > > > > > > > > > YAGNI. > > > > > > examples: > > > > > > # iterates in chunks, e.g. a very large file that wouldn't fit all in > RAM > > > zip(*[iter(x)]*32, and_then=lambda res, _: (yield res)) > > > > I'm honestly not sure how useful this really is in practice. Iterating > > over a file is already going to be chunked. What do you gain by > > wrapping it up in an opaque zip call? > > > > > # strict zip > > > sentinel = object() > > > def zip_eq(res, iters): > > > if res or any(next(x, sentinel) is not sentinel for x in iters): > > > raise ValueError > > > zip(a, b, c, and_then=zip_eq) > > > # this would ideally be zip.strict e.g. zip(a, b, c, > > > and_then=zip.strict), but w/e. > > > > So.... a messier and noisier spelling of what's already in this > proposal... > > > > > # normal (shortest) zip but using an explicit function > > > def no_op(*args, **kwargs): > > > pass > > > zip(a, b, c, and_then=no_op) > > > > > > > ... and a messier and noisier spelling of what we already have. > > > > I say again, YAGNI. Give an actual use-case for the excessive > > generality of your proposal - namely, the ability to provide a custom > > function. And show that it's better with zip than just with a custom > > generator function. > > we can finally push for the no_op function, for starters. but the main > benefit is, again, being able to get the iterated values which were > silently swallowed by zip when the iteration stopped. > > also: I don't like booleans. they're not extensible, unless you consider > None. you either get it right the first time, add a new boolean argument > later, or use enum.Flag from the beginning. this callback-based API > sidesteps all these issues. > > and just in case maybe zip(strict=True) should be zip(errors=True) and > we can later change it to zip(errors="replace", value=Foo) to get > zip_longest >.< (no really bools = bad please don't use them in new APIs) > > > > 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/UAQGBSUUFSQJRE56VGTHVXAHCJHUAYTM/ > > 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/F43SYFQAK7O7TVUGLHMKIKJDESES4W25/ > 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/5K7RHW6PWIU2XHKHZ2QKV6FRKJIBMFHZ/ Code of Conduct: http://python.org/psf/codeofconduct/
