**Reply to Eric**

Basically, *big grin* :)

**Unbounded tuples**

Pradeep, do you think we should include support for unbounded tuples in the PEP? I'd prefer to hold off - partly because a) I'd prefer not to clutter the section on `Union` with the extra rules that unbounded tuples imply - but mainly because - well, actually, this is something I haven't said expounded on properly yet:

I think it could be really intuitive if an ellipsis could eventually be used to represent the unknown parts of shapes, as in this doc https://docs.google.com/document/d/16r14MCVtd46whXwS4SdeiycIgIs0Dxvj8ePqH-Spas0 I wrote as a summary of discussion in one of the tensor typing meetings. This is incompatible with what the ellipsis means in `Tuple` currently, and what we would be committing ourselves to if we did support unbounded tuples in this PEP.

Basically, I want to postpone discussion on that bag of worms until this PEP is done. Is that alright, or do you think there are strong reasons to include it?

**Tensor[Any, ...]**

Ah, I'd missed Guido's comment that this is not valid syntax. Damn.

`Tensor[*Tuple[Any, ...]]` is certainly one option, but for the reasons in the previous section I don't like that it forces us into allowing unboundedness.

Could we perhaps just say that an unparameterized `Tensor` *behaves* as if it were `Tensor[Any, ...]` despite this not being valid syntax? How ugly a special-case would it be?

**Arbitrary-rank tensors**

Oh, man, super well-caught! You're right, committing to invariance by default does put us in a tricky situation.

But then - trying this with a regular `TypeVar`, mypy seems to be happy with the following:

```
from typing import Generic, TypeVar

T = TypeVar('T')

class Tensor(Generic[T]):
    pass

def expects_arbitrary_tensor(x: Tensor):
    pass

def expects_concrete_tensor(x: Tensor[int]):
    pass

x: Tensor = Tensor()
expects_concrete_tensor(x)

y: Tensor[int] = Tensor()
expects_arbitrary_tensor(y)
```

Any idea why that works?

> Both are unsound.

I'd actually be much more strongly in favour of the option where `Tuple[Any, ...]` is compatible with `Tuple[int, str]`. `TypeVar` is invariant by default too, but in order to support gradual typing doesn't it *have* to behave such that `Tuple[int]` is compatible with `Tuple[Any]`?

Could you expand on why that first option is unsound?


On Tue, 2 Feb 2021 at 04:57, Eric Traut <eric@traut.com> wrote:
I just published a new version of Pyright that implements full support for [PEP 637](https://www.python.org/dev/peps/pep-0637/) (indexing with keywords and unpack operators). This, in combination with the PEP 646 support, allows you to use the nicer syntax for variadic type variable unpacking (`*Ts` versus `Unpack[Ts]`). Enjoy!

--
Eric Traut
Contributor to Pyright and Pylance
Microsoft Corp.
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: mrahtz@google.com