classification
Title: Support annotations in signature strings.
Type: enhancement Stage: needs patch
Components: Library (Lib) Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, eric.snow, gvanrossum, levkivskyi, lukasz.langa, pablogsal, potomak, shihai1991
Priority: normal Keywords:

Created on 2019-07-03 23:45 by eric.snow, last changed 2019-12-01 14:01 by potomak.

Messages (9)
msg347247 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-07-03 23:45
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.
msg348139 - (view) Author: Giovanni Cappellotto (potomak) * Date: 2019-07-19 02:37
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?
msg348182 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-07-19 16:01
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).
msg348496 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-07-26 15:53
+1 on using a string for Parameter.annotation and Signature.return_annotation.
msg348556 - (view) Author: Giovanni Cappellotto (potomak) * Date: 2019-07-27 18:09
> 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.
msg349184 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-08-07 17:50
> 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.
msg349210 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-08-08 04:16
> 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.
msg357676 - (view) Author: Batuhan (BTaskaya) * Date: 2019-12-01 11:59
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?
msg357679 - (view) Author: Giovanni Cappellotto (potomak) * Date: 2019-12-01 14:01
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>
> _______________________________________
>
History
Date User Action Args
2019-12-01 14:01:56potomaksetmessages: + msg357679
2019-12-01 11:59:07BTaskayasetnosy: + BTaskaya, pablogsal
messages: + msg357676
2019-08-11 08:50:48shihai1991setnosy: + shihai1991
2019-08-08 04:16:36gvanrossumsetmessages: + msg349210
2019-08-07 17:50:34levkivskyisetnosy: + gvanrossum, lukasz.langa
messages: + msg349184
2019-07-29 18:39:03nanjekyejoannahsetnosy: - nanjekyejoannah
2019-07-27 18:09:26potomaksetmessages: + msg348556
2019-07-26 15:53:34eric.snowsetmessages: + msg348496
2019-07-22 15:15:14nanjekyejoannahsetnosy: + nanjekyejoannah
2019-07-19 16:01:19levkivskyisetmessages: + msg348182
2019-07-19 02:37:48potomaksetmessages: + msg348139
2019-07-15 03:40:18potomaksetnosy: + potomak
2019-07-05 20:01:32levkivskyisetnosy: + levkivskyi
2019-07-03 23:45:26eric.snowcreate