[issue47006] PEP 646: Decide on substitution behavior

Guido van Rossum added the comment: We need to move on this, because the outcome of this discussion is a release blocker for 3.11b1 -- the next release! -- priority: normal -> release blocker type: -> behavior ___ Python tracker

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: Ok, https://github.com/python/cpython/pull/32341/files is a reference of how the current implementation behaves. Fwiw, it *is* mostly correct - with a few minor tweaks it might be alright for at least the 3.11 release. In particular, instead of dealing with

[issue47006] PEP 646: Decide on substitution behavior

Change by Matthew Rahtz : -- keywords: +patch pull_requests: +30396 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32341 ___ Python tracker ___

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: [Guido] > 1. Some edge case seems to be that if *tuple[...] is involved on either side > we will never simplify. Alright, let me think this through with some examples to get my head round it. It would prohibit the following difficult case: class

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: Apologies for the slow reply - coming back to this now that the docs and pickling issues are mostly sorted. [Serhiy] > > Alias = C[T, *Ts] > > Alias2 = Alias[*tuple[int, ...]] > > # Alias2 should be C[int, *tuple[int, ...]] > > tuple[int, ...] includes also

[issue47006] PEP 646: Decide on substitution behavior

Serhiy Storchaka added the comment: > 1. Some edge case seems to be that if *tuple[...] is involved on either side > we will never simplify. Or perhaps a better rule is that *tuple[...] is never > simplified away (but fixed items before and after it may be). I do not understand this. Do you

[issue47006] PEP 646: Decide on substitution behavior

Serhiy Storchaka added the comment: > Alias = C[T, *Ts] > Alias2 = Alias[*tuple[int, ...]] > # Alias2 should be C[int, *tuple[int, ...]] tuple[int, ...] includes also an empty tuple, and in this case there is no value for T. > Oh, also interesting - I didn't know about this one either.

[issue47006] PEP 646: Decide on substitution behavior

Guido van Rossum added the comment: I'd like to look at this as a case of simplifying something to its simplest canonical form, but no simpler. This is what the existing fixed-typevar expansion does: e.g. tuple[str, T, T][int] becomes tuple[str, int, int]. I propose that we try to agree on

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: P.s. To be clear, (I think?) these are all substitutions that are computable. We *could* implement the logic to make all these evaluate correctly if we wanted to. It's just a matter of how much complexity we want to allow in typing.py (or in the runtime in

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: [Guido] > What would be an example of a substitution that's too complex to do? We also need to remember the dreaded arbitrary-length tuple. For example, I think it should be the case that: ```python T = TypeVar('T') Ts = TypeVarTuple('Ts') class

[issue47006] PEP 646: Decide on substitution behavior

Serhiy Storchaka added the comment: The first case will be practically fixed by GH 32030 after chenging the grammar to allow unpacking in index tuple: A[*B]. Two other cases will be fixed by GH 32031. It does not require any C code. In the last case no error is raised because some error

[issue47006] PEP 646: Decide on substitution behavior

Jelle Zijlstra added the comment: It's simple if you only look at simple examples. Here are some examples current main (with Serhiy's patch for the Python version of typing) gets wrong: >>> from typing import * >>> Ts = TypeVarTuple("Ts") >>> T1 = TypeVar("T1") >>> T2 = TypeVar("T2") >>>

[issue47006] PEP 646: Decide on substitution behavior

Guido van Rossum added the comment: I think I'm with Serhiy, I don't understand the hesitance to transform tuple[*Ts][int, str] into tuple[int, str]. What would be an example of a substitution that's too complex to do? -- ___ Python tracker

[issue47006] PEP 646: Decide on substitution behavior

Serhiy Storchaka added the comment: I am for consistent behavior. If return GenericAlias(GenericAlias(tuple, Unpack[Ts]), (int, str)) for tuple[*Ts][int, str], we should also return GenericAlias(GenericAlias(list, T), int) for list[T][int], etc. And it will cause multiple problems: * A

[issue47006] PEP 646: Decide on substitution behavior

Change by Alex Waygood : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47006] PEP 646: Decide on substitution behavior

Jelle Zijlstra added the comment: Thanks Matthew! Merged PRs can still be reverted, and we have some time before the feature freeze. I'd like to hear what Guido and Ken think too. If we go with the GenericAlias substitution, we need to make sure that such aliases still work as base class.

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: (Having said that, to be clear: my preferred solution currently would still be the solution where we just return a new GenericAlias for anything involving a TypeVarTuple. The crux is what Serhiy is happy with.) --

[issue47006] PEP 646: Decide on substitution behavior

Matthew Rahtz added the comment: Thanks for starting this, Jelle - I was a bit unsure about how to proceed here. Given that https://github.com/python/cpython/pull/31800 is already merged, I'd also propose something halfway between the two extremes: return a sensible substitution when the

[issue47006] PEP 646: Decide on substitution behavior

Change by Jelle Zijlstra : -- nosy: +mrahtz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47006] PEP 646: Decide on substitution behavior

New submission from Jelle Zijlstra : We've had some disagreement about the behavior of TypeVarTuple substitution related to PEP 646, and the discussion has now spilled around multiple PRs. I'd like to use this issue to come to an agreement so we don't have to chase through so many different