PEP 696: Add further clarification and edge cases #2902
Conversation
Gobot1234
force-pushed
the
TypeVar-defaults
branch
2 times, most recently
from
ba19037
to
b37c069
Compare
pep-0696.rst
Outdated
| '''' | ||
| Currently ``TypeVarTuple``\s as defaults are not supported due to | ||
| :ref:`scoping-rules` not allowing usage of ``TypeVarLikes`` from outer | ||
| scopes and multiple ``TypeVarTuple``\s cannot appear in the same |
There was a problem hiding this comment.
I think you mean to say that "TypeVarTuple's from outer scopes are not supported in default types". The scoping rules don't dictate this, but there are other good reasons to disallow this.
Also, I'm not sure what you mean by "multiple TypeVarTuples cannot appear in the same signature". Normally, "signature" refers to the parameter list of a function. Are you referring here to the type expression used for the default type? Why is it illegal for multiple TypeVarTuples to appear here? Is it legal for the same TypeVarTuple to appear multiple times, as in tuple[int, *Ts] | tuple[str, *Ts]?
There was a problem hiding this comment.
The scoping rules don't solely mean that they aren't allowed in defaults, it is also the combination that there aren't any cases where you can have a TypeVarTuple default to another and have be it resolved because you can't have
class Foo[*Ts, *Us = *Ts]: ...or because you can't have defaults in functions.
Unless I'm missing something there aren't any cases where you can use a TypeVarTuple with a TypeVarTuple default so they should just be disallowed.
cc @erictraut