This is copied from python/typing_extensions#105.

Waiting for the other reviewers to pipe in? This seems pretty straightforward.

The PEP hasn't been accepted yet!

Planning to hit the merge button the moment the PEP is accepted :)

PEP 702 has been accepted, but it's changed since this PR. I'll update the PR soon to put the decorator in warnings and sync the implementation from typing-extensions.

The purpose of that is supposed to be to allow third-party runtime tools to detect that the original object was decorated with @deprecated. Is that insufficient?

The issue is when using deprecated the way Zac-HD wrote (Annotated[T, warnings.deprecated("message")]), no object is being decorated here (in other words, deprecated("message") returns another function yet to be called with the decorated object)

The purpose of that is supposed to be to allow third-party runtime tools to detect that the original object was decorated with @deprecated. Is that insufficient?

The issue is when using deprecated the way Zac-HD wrote (Annotated[T, warnings.deprecated("message")]), no object is being decorated here (in other words, deprecated("message") returns another function yet to be called with the decorated object)

Got it. What if we did something like this?

diff --git a/Lib/warnings.py b/Lib/warnings.py
index 36da0e75c6..fc8a10e71f 100644
--- a/Lib/warnings.py
+++ b/Lib/warnings.py
@@ -621,6 +621,7 @@ def wrapper(*args, **kwargs):
                 f"a class or callable, not {arg!r}"
             )

+    decorator.__origin__ = deprecated
     return decorator

Then third-party code could do checks like this:

from typing import get_origin
from warnings import decorated

if get_origin(obj) is deprecated:
    ...  # it was a wrapper function returned by `warnings.deprecated("message")`

Doesn't seem to be get_origin's primary use (maybe docs should be updated), but that would avoid completely refactoring the current implementation!

Doesn't seem to be get_origin's primary use

It's already sorta awkwardly overloaded in what it means tbh — the __origin__ attribute of ParamSpecArgs instances doesn't really have the same semantics as the __origin__ attribute of generic aliases :)

A class seems somewhat more elegant to me, but yeah, that would work.

I'm OK with making it a class. It's not what the object is meant for, but it's a reasonable extension.

Using __origin__ feels hacky and wouldn't provide an easy way to get the deprecation message out.

Thanks @AlexWaygood for the review! I pushed some changes.