types.UnionType (deprecated alias for typing.Union)

I had assumed that merging the two types would mean the types name becomes preferred (as it's an interpreter type). I agree it would be useful to clarify which (or both) of the names to use. I've very likely missed prior discussion on this, though!

A

In general I see types as the place for interpreter types that don't have a better home. Other typing-related interpreter types (TypeVar, ParamSpec, TypeVarTuple, TypeAliasType) also live in typing not types.

I'm generally in favor, except for blanket deprecating NoReturn. This should stay non-deprecated for return types, similar to what is currently suggested by the Modernizing Superseded Typing Features document (written by me, so not a third opinion). I see no reason to deprecate NoReturn in this case, especially as I find it more readable. I don't have a very strong opinion on this, though.

I would like to soft deprecate NoReturn, because right now it is easy for me to explain the difference like: "NoReturn is just an old deprecated name for Never". It would be much harder to explain if there are any nuances.

I have no strong opinion on NoReturn. To me it reads slightly better than Never in return annotations. But I can also see the arguments that it's better to have only one preferred way of doing things. I also understand the argument that it's confusing to beginners who think that functions which have no return statements in them "never return", not realising that None is a more appropriate annotation for these functions.

The other proposed soft deprecations all sound reasonable to me. I'm not wild about using the term "soft deprecation" in documentation, as I don't think it's self-evident to users what it means for something to be "soft-deprecated": you almost always need some explanation of what some specific soft deprecation actually means, practically, if you want users to have clarity about what API is good to use and what isn't. (The existing soft deprecations in typing have slightly different policies laid out in the docs to other soft deprecations in the stdlib!)

But that's just about how we describe the soft deprecations in the docs, not about whether we do them or not.

FWIW I agree with soft-deprecating NoReturn and recommending Never in all cases. I don't think NoReturn has any advantage in readability that justifies two aliases for the same thing.