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 <gu...@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-le...@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/NLWB7FVJGMBBMCF4P3ZKUIE53JPDOWJ3/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/QFKBMFP5SGW6DNKTYX3SGGARYWJMQKVK/ Code of Conduct: http://python.org/psf/codeofconduct/