Well done Brandt! Even if only a few people had issues with zip(), I think that it was a long awaited feature. It's great to have it in Python 3.10! It wasn't trivial or convenient to emulate the feature (check manually the length) on Python 3.9 and older. zip(strict=True) should help to write more reliable code. Maybe it's time to review stdlib code to check if some functions would deserve the addition of strict=True? I had a look and found a few suspicious usage of zip(). But I'm not sure if we want to make these functions stricter. (*) For example, ast._Unparse.visit_Compare() uses "for o, e in zip(node.ops, node.comparators):" which expects that AST is correct. But many projects modify AST and even generate AST from scratch. On the other hand, tolerating minor inconsistencies can also be seen as a feature for ast.unparse(). (*) Another example: dis.findlinestarts() expects co_lnotab has a length which a multiple of 2, but PyCode_New() doesn't provide such warranty: byte_increments = code.co_lnotab[0::2] line_increments = code.co_lnotab[1::2] for byte_incr, line_incr in zip(byte_increments, line_increments): ... Hum, maybe it's a bug in codeobject.c which should be stricter. The file uses "Py_ssize_t size = PyBytes_Size(co->co_lnotab) / 2;". Well, that's a minor issue. I don't expect a bug if co_lnotab has an odd length, the last byte is simply ignored. (*) Another example in inspect.getclosurevars(): nonlocal_vars = { var : cell.cell_contents for var, cell in zip(code.co_freevars, func.__closure__) } I'm not sure that func.__closure__ and func.__code__.co_freevars are always consistent. For example, PyFunction_SetClosure() doesn't enforce. Victor Le mer. 17 juin 2020 à 01:14, Guido van Rossum <guido@python.org> a écrit :
After taking a break to recapitulate from the vigorous debate, Brandt Bucher has revised PEP 618 and submitted it for review. I volunteered to be PEP-Delegate (the new term for the outdated BDFL-Delegate) and the SC has approved me for this role. (Note that Antoine, the PEP's sponsor, declined to be the lightning rod, er, PEP-Delegate.)
I have now reviewed the PEP and skimmed some of the more recent discussion about the topic. It is clear that no solution will win everyone over. But most seem to agree that offering *some* solution for the stated problem is better than none.
To spare us more heartache, I am hereby accepting PEP 618. I expect that the implementation will land soon.
I have two very minor editorial remarks, which Brandt may address at his leisure:
- The "Backward Compatibility" section could be beefed up slightly, e.g. by pointing out that the default remains strict=False and that zip previously did not take keyword arguments at all.
- The error messages are somewhat odd: why is the error sometimes that one iterator is too long, and other times that one iterator is too short? All we really know is that not all iterators have the same length, but the current phrasing seems to be assuming that the first iterator is never too short or too long.
Congratulations, Brandt!
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NLWB7FVJ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.