A more useful and less divisive future for typing?

[mikeshardmind (Michael H)]

@erictraut

You’re ignoring an important part of that statement. The authors admitted that they didn’t have a specific use case in mind. Adding functionality to the type system when there is no known use case is not a good idea, and I applaud the PEP authors for recognizing this.

I believe I addressed that part directly. Your primer run shows there are real use cases for it. That the authors did not themselves have a case doesn’t mean there aren’t cases.

@erictraut

This was not a case that involved consistency. In fact, the functionality that they removed from the spec was inconsistent with existing uses of Union and ran counter to the efforts to deprecate Union in favor of |. By removing this functionality, they made the spec more consistent with the existing type system.

How so? Generic[*Ts] is fine, but then how do you type some return types based on this? In my mind the mistake is thinking Union can and should be deprecated, rather than thinking of | as shorthand that is more ergonomic in most cases.

Toy example below, but there are plenty of more interesting cases than this with data workflows, as your primer run reveals.

from typing import Self

class ExampleIterator[*Ts]:
    def __init__(self, given: tuple[*Ts]) -> None:
        self.given = given
        self.it = iter(given)
    
    def __iter__(self) -> Self:
        return self

    def __next__(self):
        return next(self.it)

@erictraut

Also, implementation complexity is a consideration that should be taken into account by PEP authors. From the time that the first draft PEP 646 was presented for general review, it took almost three years for mypy to add support for it. Pyre still hasn’t added full support, and pytype hasn’t even started to add support for it.

I understand that you as a type checker maintainer personally bear a lot of the effort involved on the implementation side of this equation, but as more and more decisions favor the ease of implementation over giving users tools to express types, typing becomes increasingly more restrictive on what can be written socially. Things go from being typed as Any or untyped because the type system can’t handle it yet, to people rewriting perfectly good code when it turns into “and it never will be supported”. Is it reasonable to say the implementation agnostic specification itself should cater to how implementations have boxed themselves into a corner by special-casing things in their code? Is it not better to specify more and just let those who want the feature in their type checker of choice go help contribute to it?

I don’t make that argument lightly here, there are plenty of cases where “you aren’t going to need this” or “This should be supported, but maybe we should spell it a different way for this particular case because of [reasons]” are quite reasonable responses, but I can’t see how such an argument applies here.