On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote: > Can you think of a single case where a zip_equal() (either pre-exisiting or > roll your own) would not work, but the concretizing version would?
That's easy: if the body of your zip-handling function has side-effects which must be atomic (or at least as atomic as Python code will allow). An atomic function has to either LBYL (e.g. check the lengths of the iterables before starting to zip them), or needs to be able to roll-back if a mismatch is found at the end. In the most general case, we can't roll-back easily, or at all, so if your requirements are to avoid partial operations, then you must concretize the input streams and check their lengths. But I don't think that's a problem for this proposal. Nobody is saying that zip_strict can solve all problems, and we shouldn't hold it against it that it doesn't solve the atomicity problem (which is very hard to solve in Python). -- Steven _______________________________________________ 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/DZ3WZGWIXS4XJ563BTOW6GMXSVKSETYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
