+1 on almost always expecting my iterators to be the same length when I pass them to zip. I struggle to think of a time when I haven't had that expectation. To people asking whether I would catch the error that zip_strict would raise, almost certainly not. I rarely catch ValueError other than to log or raise a different exception. I don't really care about the state of the iterators post zip_strict (as I would generally not be catching that exception) but I suppose it should be the same as zip, evaluate left to right. Seems to me that deprecating the current zip behavior is more trouble than it's worth, just add zip_strict to itertools and call it a day. If zip_strict turns out to be super popular than we could revisit changing the behavior of zip. I don't think we need to have new versions of map, there isn't map_longest in itertools. Also building variant maps is trivial: def map_strict(f, *iters): return starmap(f, zip_strict(iters)) - Caleb Donovick On Fri, Apr 24, 2020 at 10:57 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
24.04.20 07:58, Andrew Barnert via Python-ideas пише:
And not only that, the PEP for this first step has to make it clear that it’s useful on its own—not just to people like Serhiy who eventually want to replace zip and see it as a first step, but also to people who do not want zip to ever change but do want a convenient way to opt in to checking zips (and don’t find more-itertools convenient enough) and see this as the _only_ step.
Don't consider me an apologist. I just think that might be a good idea. But now we do not have enough information to decide. We should wait several months or years. And even if it turns out that most users prefer zip_equal(), the cost of changing zip() may be too high. But we should not reject this possibility.
While we discuss zip(), we should not forget about map() and other map-like functions (like Executor.map()). All that was said about zip() is applied to map() too, so after adding zip_equal() and/or zip_shortest() we will need to add corresponding map variants. _______________________________________________ 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/NJB46S... Code of Conduct: http://python.org/psf/codeofconduct/