fix: Parse deprecation message from expression arguments

[connesy]

Update the deprecated method to parse the deprecation message from the expression arguments instead of relying on string parsing.

Fixes #4

[connesy]

@pawamoy Not sure how to fix the typing issue, as the Decorator.value field is typed as str | Expr, but the actual value is ExprCall?

[pawamoy]

I'm far from a typing expert so I'll simply recommend adding a # type: ignore[...] comment for the issue you mention 😅 As far as I can tell it's not possible to use the deprecated decorator without arguments, so it should always be an ExprCall.

[connesy]

I'm far from a typing expert so I'll simply recommend adding a # type: ignore[...] comment for the issue you mention 😅 As far as I can tell it's not possible to use the deprecated decorator without arguments, so it should always be an ExprCall.

I think the bigger question is whether the Decorator.value attribute should be annotated as str | Expr. Will it always be a ExprCall for an instance of Decorator?

[pawamoy]

No! Decorators can be arbitrary expressions since a few Python versions:

@(lambda func: some_wrapper(func, some_arg=0))
def my_func(): ...

Even before that they could have been a single name, or an attribute (no calls):

@dec
def func(): ...

@obj.dec
def func(): ...

[connesy]

I've added a check for whether decorator.value is an instance of ExprCall: 5c6acc4 (#5)

[pawamoy]

Thanks again!

[connesy]

Thank you!
Apologies for taking up your night. I appreciate the fast responses 🙂

You are doing great work with these packages 👍

[pawamoy]

No apologies required ☺️! Thanks for your contributions and for the kind words ❤️

[pawamoy]

Version 1.1.0 released by the way!