Matthew Rahtz wrote:
Hi everyone,
We've got to the stage now with PEP 646 that we're feeling pretty happy
with it. So far though we've mainly been workshopping it in typing-sig, so
as PEP 1 requires we're asking for some feedback here too before submitting
it to the steering council.
If you have time over the next couple of weeks, please take a look at the
current draft and let us know your thoughts:
https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
sections are out of date; https://github.com/python/peps/pull/1880
clarifies which grammar changes would be required, now that PEP 637 has
been rejected. We also have a second PR in progress at
https://github.com/python/peps/pull/1881 clarifying some of the motivation.)
Thanks!
Matthew and Pradeep
Hi,
I'm very late to the discussion -- I relied on the typing-sig and SC to
handle this, but now that I'm on the SC, I no longer have that luxury :)
This mail has my own opinions, not necessarily the SC's.
I've read the PEP, and I quite like it! It's clear that typing-sig
thought this through very well.
The thing that surprised me is the proposed changes that affect more
than typing annotations. Quite deep in the PEP, the "Grammar Changes"
section explains the (quite exciting) change to make star-unpacking
possible in normal indexing operations, e.g.::
idxs_to_select = (1, 2)
array[0, *idxs_to_select, -1] # Equivalent to [0, 1, 2, -1]
However, the PEP is silent about indexing assignment, e.g.::
array[0, *idxs_to_select, -1] = 1
IMO, it would be very confusing to not keep these in sync. If they are,
the assignment change should be documented and tested appropriately. Is
that the plan?
For a second point, the PEP says:
this PEP disallows multiple unpacked TypeVarTuples within a single type
parameter list. This requirement would therefore need to be implemented in type
checking tools themselves rather than at the syntax level.
Typing annotations are sometimes used for other things than *static*
typing, and I wouldn't be surprised if type checkers themselves started
allowing this (as a non-standard extension in cases where things aren't
ambiguous):
def tprod(Generic[*T1], Generic[*T2]) -> Generic[*T1, *T2]: ...
If multiple unpackings in a tuple aren't blocked by the compiler, they
should be tested and documented as syntactically valid annotations --
just not valid static typing annotations (even though other uses are
currently deprecated). In particular, once the compiler allows multiple
unpackings, disallowing them at the syntax level later would mean
breaking backwards compatibility.
Do we share that view?
And after reading the PEP again, I'm unclear on some details in the
Aliases section. Could you please clarify these examples for me?
SplitDataset = Tuple[Array[*Ts], Array[*Ts]]
SplitDataset[Height] # Valid? What would this be equivalent to?
TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]]
TwoArrays[Height] # Valid? Equivalent to what? How to specify this fully?
_______________________________________________
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/5YLXBCYX4VAGXWFVYLLL5RMTBXCKWPVU/
Code of Conduct: http://python.org/psf/codeofconduct/
