> Sure, but I think cases where you want that assumption _checked_ are a lot 
> less common. There are lots of postconditions that you assume just as often 
> as “x, y, and z are fully consumed” and just as rarely want to check, so we 
> don’t need to make it easy to check every possible one of them.

It seems that our experiences differ rather significantly. This isn't a "rare" 
assumption for me, and it's unique because it's one that `zip` already handles 
internally.

> Of course, the fact that zip() is the shorter form that everyone is used to 
> means that, even if a strict argument is added, few people will bother adding 
> it.

I know that I, and everyone on my team, would use it frequently!

> The possible solution is to introduce zip_shortest() with the current 
> behavior of zip(), make zip() emitting a pending deprecation warning when 
> some data is ignored, and after long period of deprecation make it raising an 
> exception if some data is ignored.

Unlike some on this thread, I think the default behavior for `zip` is fine. 
It's not broken, and it *should* be able to handle infinite iterables by 
default. This isn't just a "band-aid" fix; it's a feature that allows many (if 
not most) call sites to check an important assumption that's easy to check 
inside zip (there's literally logic already handling this case) but heavy to 
check at every call site.

> I'm gonna need someone else to write the implementation.

I'll take care of that. Feel free to reach out to me off list to coordinate. :)

Since this has received some degree of support here, I'll go ahead and open a 
BPO issue. For anyone wondering about semantics, iterator consumption *should* 
be the same as any old `zip` usage... it seems obvious to me just to raise a 
ValueError instead of a StopIteration when the option is enabled. If there are 
arguments against it, lets take it up on BPO!
_______________________________________________
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/PETIP2OUN7Y6ZV5XIOY3QIIJ5KVIEPFI/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to