On Wed, 22 Apr 2020 12:52:01 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Apr 22, 2020 at 01:07:07AM +0200, Antoine Pitrou wrote:
On Wed, 22 Apr 2020 08:34:56 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
21.04.20 11:15, Antoine Pitrou пише:
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.
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.
Wait, are suggesting that zip should raise by default (after a suitable deprecation period)?
"if some data is ignored"
Yes, I saw that and I understood it. It goes without saying that it would only raise if there was data remaining in one or more iterables after some iterable was exhausted. I didn't think I needed to spell out every fine detail to ask such a simple question.
Are you suggesting that in the future, after a suitable deprecation period, the default zip() builtin function should raise an exception "if some data is ignored"?
Is this is serious proposal that you would like to see happen, or are you just mentioning it for the sake of mentioning all the options?
Ideally, that's what it would do. Whether it's desirable to transition to that behaviour is an open question. But, as far as I'm concerned, the number of times where I took advantage of zip()'s current acceptance of heteregenously-sized inputs is extremely small. In most of my uses of zip(), a size difference would have been a logic error that deserves noticing and fixing. Regards Antoine.