Typing spec update: `type[]` distributes over unions

[InSyncWithFoo]

• PR: #1841: Specify that type[] distributes over unions
• Discussion: Specs clarification: type[A | B] is equivalent/the same as type[A] | type[B]

As noted in the Python Forum discussion, all major type checkers already consider this to be the case; backward compatibility problems will thus be minimal if not non-existent. This proposal is only to formalize the concept.

Relevant concerns raised during the discussion were about wording, which have since been addressed in the PR.

TC Sign-off

• [x] Carl
• [x] Eric
• [x] Jelle
• [x] Rebecca
• [x] Shantanu

[mikeshardmind]

I don't think all relevent concerns were addressed.

The open question, as you mentioned, is whether we keep type[] defined as-is (though without constructibility, which is not specified but is implemented, unsoundly, by all type checkers) and add a new syntax sugar for that constructible-type intersection, or we redefine type[] to mean that constructible-type intersection. I agree that the latter probably agrees better with much current usage of type[]. Both are breaking changes in practice for some current code. The former is more expressive, in that it still gives you a way to spell the always-covariant-but-not-constructible “C and all subclasses of C” type[].

https://discuss.python.org/t/specs-clarification-type-a-b-is-equivalent-the-same-as-type-a-type-b/60912/26

One of the options here is not compatible with this, and has not reached resolution.

[carljm]

I agree that the option of redefining type as described there is not compatible with this spec clarification, but since it's also not compatible with other clear wording already in the spec about what type means, I don't see it as a barrier to this clarification. Whether we make this clarification or not, redefining type will require changing the spec, as well as the behavior of type checkers, which will be a much bigger challenge than changing the spec.