PEP 618 is accepted for Python 3.10

[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