On 12. 01. 22 17:58, Guido van Rossum wrote:
On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin <pvikt...@redhat.com
<mailto:pvikt...@redhat.com>> wrote:
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/
<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
<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
<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?
The previous SC approved the PEP despite this.
If you want to convince the SC to request this feature parity in the
PEP, I won't stop you.
But unless that happens I would rather not update the PEP again (it's
been tough to get to this point).
Maybe you can write a separate PEP? That would probably be simpler for
all involved (the PEP 646 authors would not have to be involved, and the
separate PEP would be very straightforward.
As I learned after drafting that question, at least some members of the
previous SC feel like this went without saying. So I'm a bit surprised
by this reply. Guess it goes to show that PEPs need to be precise :)
Looking at the current grammar, I see that the proposed change to
`slices` will affect indexed assignment. And the reference
implementation also allows it.
With that in mind, can we treat this as this as a clarification, rather
than a substantial change? A simple note that indexed assignment is also
affected should be enough. (Tests/docs in the eventual implementation
won't be so simple, but they'll be needed anyway.)
Of course, if __setitem__ isn't meant to be affected, the proposed
grammar change needs to be revisited.
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]: ...
I don't think that sentence is trying to forbid this. The problem
appears in things like
def foo(*args: tuple[*Ts1, *Ts2]) -> ...
Maybe the wording in the PEP can be imrpoved?
Looks like it can -- the current wording does forbid it:
As of this PEP, only a single type variable tuple may appear in a type
parameter list
But improving that smells like a rabbit hole. It's probably better to
keep it disallowed (as a static typing expression) in the current PEP.
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?
Agreed that the syntax with multiple stars will not be deprecated at
runtime, but type checkers may reject it. (Just as type checkers reject
many other programs that would run fine.)
+1, glad we're on the same page here.
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?
I'll leave this to the PEP authors to address.
Sounds good. Thank you!
_______________________________________________
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/OFQ27ZAQWPYLZAVPZFJH3K6LL3I7FWDR/
Code of Conduct: http://python.org/psf/codeofconduct/
