PEP 618 https://www.python.org/dev/peps/pep-0618 discussions are still on going.  This issue is being filed to track an implementation, assuming the PEP is accepted and one is decided upon.

I'm filing it now, as I can at least use the issue for documentation enhancements of the existing zip() behavior.

New changeset 6a5d3ff67644af42b1a781be2eacb2e82913441c by Gregory P. Smith in branch 'master':
bpo-40636: Clarify the zip built-in docstring. (GH-20118)
https://github.com/python/cpython/commit/6a5d3ff67644af42b1a781be2eacb2e82913441c

New changeset c3d025a86a60348f19551bd9921304c5db322531 by Miss Islington (bot) in branch '3.8':
bpo-40636: Clarify the zip built-in docstring. (GH-20118)
https://github.com/python/cpython/commit/c3d025a86a60348f19551bd9921304c5db322531

New changeset 310f6aa7db8dd48952ed718111ce0f016b1c8ef9 by Guido van Rossum in branch 'master':
bpo-40636: PEP 618: add strict parameter to zip() (GH-20921)
https://github.com/python/cpython/commit/310f6aa7db8dd48952ed718111ce0f016b1c8ef9

New changeset 59cf853332a82ce92875ea3dd6bba08e1305a288 by Ram Rachum in branch 'master':
bpo-40636: Documentation for zip-strict (#20961)
https://github.com/python/cpython/commit/59cf853332a82ce92875ea3dd6bba08e1305a288

Ram, please fix the typo pointed out on github https://github.com/python/cpython/commit/59cf853332a82ce92875ea3dd6bba08e1305a288#r40044022

I'll fix that typo.

Tests test_zip_pickle_stability and test_zip_pickle_strict_stability look excessively strict. Why did we need them if there are other pickle tests? They prevent implementing optimizations like in issue36694.

That's fair.  How do other builtins validate their pickling implementation?

Since the pickling goes through __reduce__/__reduce_ex__ we could instead test that those methods return the expected results, that pickling roundtrips, and that unpickling those exact byte strings produces the expected value?

For other types we do not have such strict tests. We just test that pickling roundtrips (it is already tested for zip() in other tests). There are few tests that unpickling some exact byte strings produces the expected value, but these tests are in pickletester.py, because they test the unpickling machinery. If unpickling of some type depends on some private constructor (like re._compile), that constructor can be tested separately.

So I think that these tests can be removed.

Sounds good, go for it. I assume @brandtbucher won't mind.

Yep, fine by me. I can remove them later today (unless Serhiy beats me to it).

New changeset 27f9dafc2ba51864a9bc2fe5d6293eb4fd887bce by Brandt Bucher in branch 'master':
bpo-40636: Remove overly-strict zip pickling tests (GH-24109)
https://github.com/python/cpython/commit/27f9dafc2ba51864a9bc2fe5d6293eb4fd887bce