Migrate from `typing.NoReturn` to `typing.Never`

[donbarbos]

I suggest using preferred option (Never) to indicate the bottom type.
Using NoReturn is still popular (and more well known) I think because the types in stdlib use it (one of the reasons), I think it's worth using the option we want to promote

cc @JelleZijlstra (inspired by your recent issue on soft deprecation)

[srittau]

I see no reason to deprecate NoReturn in favor of Never for return types. NoReturn is widely used and clearer.

[donbarbos]

I see no reason to deprecate NoReturn in favor of Never for return types. NoReturn is widely used and clearer.

I'm not suggesting to mark it as deprecated, I'm just suggesting to use the preferred type

also judging by the discussion when adding Never there was an idea that this is a more preferable way starting with Python 3.11

[srittau]

I'm not suggesting to mark it as deprecated, I'm just suggesting to use the preferred type

Never is not the preferred name for return types.

[donbarbos]

Sorry, I seem to have jumped to conclusions based on this issue message (python/cpython#132941 (comment)):

I'd like to also soft-deprecate the following:
* Optional (obviated by PEP-604)
* NoReturn (prefer Never)

I already found another message that confirms your comment: python/cpython#117492 (comment)

then it remains unclear to me why soft deprecate it if we want to use continue NoReturn

[Avasam]

Whilst they are equivalent. There's a semantic difference. And typeshed is no stranger to using type name alias to express different semantic (Incomplete, Unused, MaybeNone, ...) I'm -1 on this atm.

If python/cpython#132941 is accepted to where NoReturn is considered (soft) deprecated and there's a general agreement in the Python typing community to no longer use NoReturn, then maybe.

But as it stands:

Never is not the preferred name for return types.

---

I can get behind the semantic of "a function that Never returns". But I'd want widespread agreement before changing in typeshed.

[Avasam]

Also if we go that route, I'd prefer having a lint rule to enforce that soft deprecation in https://github.com/PyCQA/flake8-pyi / https://docs.astral.sh/ruff/rules/#flake8-pyi-pyi (the more guidelines are codified/automated, the easier it is to review and stay on track)