Spec change: Clarify that `tuple` should not be prohibited as an argument to `type`

Typing
1

I would like to bring the following spec change for discussion: Clarify that `tuple` should not be prohibited as an argument to `type` by fangyi-zhou · Pull Request #2146 · python/typing · GitHub

In the current spec: Special types in annotations — typing documentation

Any other special constructs like tuple or Callable are not allowed as an argument to type.

This is in contradiction with the conformance test suite, which requires tuple to be allowed as an argument to type.

I propose to change the sentence to the following:

Any other special forms like Callable are not allowed as an argument to type.

The proposed change moves away from the ambiguous term “special constructs“ to the terminology “special form“ (with a link to glossary).

2

Should not it be Tuple instead of tuple?

3

I don’t think it means typing.Tuple but rather tuples as in type[(...)].

4

In that case I would remove markup from “tuple”.

1 Like
5

I did not think about the possibility that tuples could have been read without the quotes. However, I traced the original sentence back to PEP 484 PEP 484 – Type Hints | peps.python.org and to me it didn’t feel like the spec meant tuples (in the form of type[A, B])

1 Like
6

PEP 484 mentions Tuple, so my first guess was correct.

Any other special constructs like Tuple or Callable are not allowed as an argument to Type.

Then typing generics were replaced by simple builtin types. But there is an important difference between Tuple and tuple – the latter can be used as a base class, in issublass() and isinstance(), but the former cannot. This is why replacing Tuple with tuple caused confusion – the wording is now ambiguous, it can be interpreted in multiple ways, as was shown above.

I would simply add []: “tuple[] or Callable[]”. type[] is already used, so there is precedence.

2 Likes