A problem with bool subclassing int and JSON; excluding subclasses using "exactly()" notation? about typing HOT 8 CLOSED

This also came up in the context of Cython. Stefan Behnel's proposal is a function typing.exactly(), which can be used as for example

from typing import List, exactly
def foo(a: exactly(List[int])): ...
def bar(b: List[exactly(int)]): ...

from typing.

If there is such a facility, it should be used VERY sparingly. It's normally safe to subclass something to add functionality and have your class still work like the parent (imagine a self-sorting subclass of list - it should JSON-encode like any other list). Too much use of exactly() would disrupt that - and often in cases where it wouldn't even matter, which would just give type hinting a bad name.

+1 on the concept, but with very clear documentation that this is for the unusual cases. +1 on the name, too - it parallels PyLong_Check vs PyLong_CheckExact.

from typing.

I'm wondering if the spelling should be Exactly[t] rather than exactly(t). We don't seem to have a great rule for deciding when to use [] vs. (), but in general when something is composable as part of the type system, takes a type (or more) as arguments, and could support issubclass() or isinstance() checks, I have proposed []. Thus Callable[...], Tuple[...], Union[...], and even Optional[...], but TypeVar('T') (the upper case because it's a class instantiation). I think Exactly[...] fits in this pattern, since the run time representation must retain the information that [Ee]xactly was used, and it would make sense at run time to use e.g. isinstance(x, Exactly[int]).

from typing.

Exactly[T] looks good to me.

I think the fact that it's rather verbose is probably enough to discourage unnecesary use.

from typing.

It's a rare case, it might be better not to address it.

from typing.

Another use case (if we decide it's worth it) might be for @overload. Pickling is (conceptually) defined by a function that is overloaded for many types. Several such overloads are for exactly the builtin types (e.g. int, str) and their pickled representation is different from that of subclasses. Still, there are other ways to do this, so if we decide not to include it I won't be upset.

from typing.

@gvanrossum You tagged this "out of scope" an eternity ago. Do you think this is a feasible idea (in which case I would remove the "out of scope" label) or should we close this issue?

from typing.

Just close it.

from typing.