In early 2014 (3.3), when argument clinic was added, we added support for turning func.__text_signature__ into an inspect.Signature object.  However, at that time we did not add support for annotations (see the nested "parse_name()" in _signature_fromstr().  Annotations should be supported.

I'd expect that PEP 563 (Postponed Evaluation of Annotations) could be leveraged.

I'd like to work on this, but I'm kind of new to the codebase. Do you think I should leave this task to someone more expert on the matter?

I took a look at the function you mentioned and I was able to support simple annotations, for instance `x: int`, by evaluating `node.annotation.id`. This method doesn't work with more complex annotations thought. For instance a simple type alias (`Foo = int`, `x: Foo`) breaks this naive implementation. Another error happens if the annotation is not a simple `id`, but a subscript function application, for instance `x: List[int]`.

Do you have any suggestion for how to continue working on this task?

You might want to look into how PEP 563 is implemented, it has a utility to turn an AST back into a string (I assume this is what you want).

+1 on using a string for Parameter.annotation and Signature.return_annotation.

> You might want to look into how PEP 563 is implemented, it has a utility to turn an AST back into a string (I assume this is what you want).

Thanks for your suggestion @levkivskyi.

I took a look at https://github.com/python/cpython/pull/4390, that implements PEP 563.

In that PR `ast_unparse.c` has been introduced, that is

> a close translation of the relevant parts of `Tools/unparse.py`

Source: https://github.com/python/cpython/pull/4390#issuecomment-346554817

I have a couple of questions about how to use `ast_unparse.c`'s `expr_as_unicode` function:

1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`?
2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`?

On a side note: would it make sense to reconcile the two "unparse AST" implementations?

> +1 on using a string for Parameter.annotation and Signature.return_annotation.

Thanks for your comment @eric.snow.

From what I saw in the test I've written, right now `Parameter.annotation` and `Signature.return_annotation` return Python type classes.

At the beginning, in order to keep `Parameter.annotation`'s return type consistent with the current implementation, I tried to evaluate the annotation's "unparse AST" string output, but I was getting errors evaluating type aliases and refined types.

Returning strings would make `parse_name`'s implementation easier, but I'm wondering if would be backward compatible.

> I have a couple of questions about how to use `ast_unparse.c`'s `expr_as_unicode` function:

> 1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`?
> 2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`?

Hm, TBH I am not sure which one is better, I am leaning towards option 1, but I add more people to get some opinions.

> 1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`?
> 2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`?

I would vote for #1. If it is not up to the task that probably points to a flaw anyway.

We have exposed Tools/unparse.py under ast module, so that option also can help. @potomak are you still interested in working on this issue?

Thanks for the info.

Yes, I’m still interested in working on the issue, but lately I didn’t have
much time to do it.

If this is a high priority feel free to re-assign to someone else,
otherwise I’ll start working on it next week.

On Sun, Dec 1, 2019 at 6:59 AM Batuhan <report@bugs.python.org> wrote:

>
> Batuhan <batuhanosmantaskaya@gmail.com> added the comment:
>
> We have exposed Tools/unparse.py under ast module, so that option also can
> help. @potomak are you still interested in working on this issue?
>
> ----------
> nosy: +BTaskaya, pablogsal
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue37496>
> _______________________________________
>

This seems somewhat related to https://bugs.python.org/issue31939