Add an optional "strict" check to zip

[brandtbucher]

BPO	40353
Nosy	@vstinner, @stevendaprano, @cool-RR, @serhiy-storchaka, @brandtbucher
Superseder	bpo-40636: Provide a strict form of zip (PEP-618) requiring same length inputs

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/brandtbucher'
closed_at = <Date 2020-06-17.14:51:12.776>
created_at = <Date 2020-04-21.16:32:58.325>
labels = ['interpreter-core', 'type-feature', '3.10']
title = 'Add an optional "strict" check to zip'
updated_at = <Date 2020-06-17.14:51:12.774>
user = 'https://github.com/brandtbucher'

bugs.python.org fields:

activity = <Date 2020-06-17.14:51:12.774>
actor = 'brandtbucher'
assignee = 'brandtbucher'
closed = True
closed_date = <Date 2020-06-17.14:51:12.776>
closer = 'brandtbucher'
components = ['Interpreter Core']
creation = <Date 2020-04-21.16:32:58.325>
creator = 'brandtbucher'
dependencies = []
files = []
hgrepos = []
issue_num = 40353
keywords = []
message_count = 8.0
messages = ['366926', '366927', '366928', '366930', '366946', '366948', '366949', '371747']
nosy_count = 5.0
nosy_names = ['vstinner', 'steven.daprano', 'cool-RR', 'serhiy.storchaka', 'brandtbucher']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '40636'
type = 'enhancement'
url = 'https://bugs.python.org/issue40353'
versions = ['Python 3.10']

[brandtbucher]

As discussed on Python-ideas:

https://mail.python.org/archives/list/python-ideas@python.org/thread/6GFUADSQ5JTF7W7OGWF7XF2NH2XUTUQM/

When a keyword-only argument "strict=True" is passed to zip's constructor, a ValueError will be raised in the case where one iterator is exhausted before the others. Otherwise, no side-effects (such as iterator consumption) will be changed.

I do wonder if we can use a better keyword than "strict" here.

I'm currently working on an implementation, and @cool-RR is working on tests and docs.

[serhiy-storchaka]

It would be better to implement it as a separate function.

[serhiy-storchaka]

Also you can just get a ready implementation from more-tertools.

[cool-RR]

Here are the tests I made: cool-RR@7664097

[brandtbucher]

Slight edit: if the shortest iterator is "first", one additional item will have to be drawn from the next non-exhausted iterator. I missed that, initially.

It would be better to implement it as a separate function.

I disagree. It's not intrusive here; I think the handful of new lines this needs to fit into the existing zip implementation (which already handles most of this logic) is more maintainable than a whole new object/function living somewhere else.

Also you can just get a ready implementation from more-tertools.

I've found that there are several places where our own standard library could immediately benefit from this change.

[stevendaprano]

I don't think this is needed in the builtin zip at all. I think that there is no consensus on Python-Ideas that this is needed or desirable.

I especially don't think the API should be a keyword flag on zip. Flag arguments which change the behaviour of functions are at best a code-smell and at worst an outright anti-pattern.

It is not always practical to avoid them, but in this case it certainly is: if we need this (I'm not sure we do) then a separate zip_strict() function in itertools next to zip_longest() is better than a flag on the builtin zip.

(That's not to say that the zip_strict iterator must be an independent class to the builtin zip and itertools.zip_longest, they can share a common backend. It is the public API I am referring to.)

I've already posted an implementation on the mailing list, it is about half a dozen or so lines of Python. Another independent implementation is available from the current development branch of more-itertools, more or less the same only with a less informative error message.

Personally, the fact that this has only just hit more-itertools counts as a point against this function to me: more-itertools is the "everything including the kitchen sink" grab-bag of iterator tools, and even they didn't think they needed "zip_equal" until version literally a few days ago. It's so new it isn't even documented yet:

https://pypi.org/project/more-itertools/

[stevendaprano]

independent class

Oops, sorry I mean independent implementation.

[brandtbucher]

Looks like two issues were created. I'm going to close this one in favor of 40636, which has PRs attached and is specific to PEP-618.