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/

Reply via email to