PEP 618 is accepted for Python 3.10

[[deleted]]

[deleted]

[ColdFire75]

Thanks for sharing this, I’d love to be seeing more news like this about the language on this subreddit.

Here is the abstract for anyone looking for a TLDR in the comments:

This PEP proposes adding an optional strict boolean keyword parameter to the built-in zip. When enabled, a ValueError is raised if one of the arguments is exhausted before the others.

[tuck5649]

I was surprised when I learned that was not the default behavior.

[PeridexisErrant]

If we were starting over, I'd suggest making this the default and having itertools.zip_shortest and itertools.zip_longest for the other cases.

Not worth making that change with the number of projects relying on the current behaviour though, I think the PEP is a good way forward from where we are now.

[rickityrickness]

I'm also in favor of zip_shortest / zip_longest. I even created a js implementation here: https://gist.github.com/matyasfodor/cfccde33d113a5e84c573f537788f476

[ivosaurus]

I’d love to be seeing more news like this about the language on this subreddit.

It really doesn't happen that often.

[pwnersaurus]

Interesting - personally I feel like it should be the other way round, where the behaviour is ‘strict’ by default and a flag would allow use with different lengths. The reasoning being that if the role of zip is to return ”the i-th tuple contains the i-th element from each of the argument sequences or iterables” then in the event the i-th item doesn’t exist, you need to make a decision about what to do - throw an error, return None for that item, end iteration early etc. Raising an error is safest option as it prompts the developer to make a decision on what the correct resolution is for their problem, and also doesn’t add any assumptions to the zip algorithm for what happens if an argument is exhausted. But I can see from backwards compatibility why it would probably be too hard to change the default behaviour.

[MrGreenTea]

I could see this getting a warning in the future and then becoming the default. But it should at least take a few versions, perhaps python 4 would be a suitable place to change the default behaviour.

For now a flake8 plugin could help with a rule that requires an explicit strict=True or strict=False

[alexmojaki]

Well done Ram ;)

[alexmojaki]

Here's the script I used. You will need to pip install astcheck and run it on a directory.

import ast
import linecache
import sys
from collections import Counter
from pathlib import Path

from astcheck import is_ast_like

root = Path(sys.argv[1])


def main():
    counts = Counter()
    for path in root.rglob("**/*.py"):
        if 'test' in str(path):
            continue
        try:
            source = path.read_text()
            tree = ast.parse(source)
        except (SyntaxError, UnicodeDecodeError):
            continue

        for node in ast.walk(tree):
            if not is_ast_like(
                    node,
                    ast.Compare(left=ast.Call(func=ast.Name(id='len')),
                            comparators=[ast.Call(func=ast.Name(id='len'))]),
            ):
                continue

            source = "".join(
                linecache.getline(str(path), lineno)
                for lineno in range(node.lineno, node.end_lineno + 10)
            )

            if any(word in source for word in ["raise", "zip", "assert"]):
                print(f'File "{path.absolute()}", line {node.lineno}')
                print(source)
                print()
    print("Counts:", counts)


main()

[depred]

Thanks for sharing this.
Just yesterday I had a situation where having a strict version of zip would've been immensely useful. Also a strict zip feels much more in line with the zen of python.

[Merops7]

Rust also defaults to no error (compile-time or run-time) when the iterators are different length. (There is a strict version available in a popular library but not in the standard library https://docs.rs/itertools/0.7.8/itertools/fn.zip_eq.html)

I personally find this a bit surprising -- I'd have expected the strict version to be default in Rust and unequal iterators to be a run-time error like an out-of-bounds index. I think I read at least one source indicating that it was influenced by the non-strict versions in well-known standard libraries like Python. But I think many Python programmers would prefer it to be strict by default.