Tuple and Callable should be listed as generic variants of builtin classes

[ilevkivskyi]

Currently Callable and Tuple are listed in the section "Fundamental building blocks", I would rather move them to "Generic variants of builtin classes". Indeed, Callable[..., [Any]] could be just equivalent to collections.abc.Callable (See also this comment #133 (comment)), and Tuple[Any, ...] could be just equivalent to tuple, in the same way as List[Any] is an equivalent of list.

Also, although Optional is just a particular case of Union, maybe it should be listed in the section "Fundamental building blocks" for completeness.

[gvanrossum]

I disagree. Both typing.py and mypy special-case the heck out of these, and they support syntax that doesn't apply to regular generics.

[ilevkivskyi]

You see this more from the position of implementation, I see this more from the position of interface. Probably you are right, Callable is indeed quite special. Probably the division in PEP that exist now, could be reformulated to distinguish between "Special typing constructs" and "Generic type constructs and types" (for example). Let me explain why I think so.

This qestion appeared in the context of compromise that I discussed in #136 , namely we always raise TypeError in instance and subclass checks for special type constructs like Any, Union, etc. But probably we should allow them for generics without parameters, so that the question is whether we should allow issubclass(cls, Callable) (considering Callable a generic type construct) or prohibit this (considering Callable a special type construct). I think that we should allow this, because as you reasonably mentioned in #133

Pretty much anything you can do with collections.abc.X should be possible with typing.X

If you agree, I could make a PR to change the formulation in PEP

[gvanrossum]

I can't follow what you're arguing for any more, so just send a PR and I'll look at that. FWIW Tuple is also special because it's variadic, and because it supports the form with ellipsis.

[ilevkivskyi]

@gvanrossum I have submitted a PR #214 . Finally, I decided, that it is better to just be more precise about subclasses vs subtypes, remove the mention of issubclass in the description of Union, and add a note that it should not be used with special type constructs.

In this way I am OK with keeping the current structure of sections in PEP describing typing.py and the results of discussion in #136 could be easily added to PEP independently later (if necessary).

[ilevkivskyi]

Fixed by #214