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 <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/QFKBMFP5SGW6DNKTYX3SGGARYWJMQKVK/
Code of Conduct: http://python.org/psf/codeofconduct/
