types.UnionType was merged with wrong ~class~ (not even a class)

Core Development
31

Thank you for the detailed explanation of the Steering Council’s thinking. I think that reversion of this change so late in the release candidate phase or even in the post-release bugfix phase would bring less harm than keeping it for the period necessary for deprecation, but I accept your decision. Any chance to start deprecation in 3.14.1 instead of 3.15, considering it a bug fix?

The following operations should be deprecated:

  • types.UnionType[...]. Because types.UnionType is a class, but not a generic class.

    But typing.Union[...] should be kept – this is the purpose of typing.Union.

  • isinstance(..., typing.Union) and issubclass(..., typing.Union). Because typing.Union is not a type, it is a special form used to create type unions. Using it in the type checks is the same as using typing.Literal or typing.Final in the type checks.

    But isinstance(..., types.UnionType) and issubclass(..., types.UnionType) should be kept – I suppose this was the primary reason of exposing types.UnionType to public.

  • Some dunder attributes and methods like __origin__, __args__, __qualname__ or __mro_entries__() – but I cannot say right now which of them are harmless and are useless. We can leave this for later.

To do this, we need to separate types.UnionType and typing.Union and make the latter imitating the former. This itself is a breaking change.

7 Likes