This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author potomak
Recipients eric.snow, levkivskyi, nanjekyejoannah, potomak
Date 2019-07-27.18:09:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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, that implements PEP 563.

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

> a close translation of the relevant parts of `Tools/`


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/`?
2. Would it be better to just re-use the _AST to string_ implementation in `Tools/`?

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.
Date User Action Args
2019-07-27 18:09:26potomaksetrecipients: + potomak, eric.snow, levkivskyi, nanjekyejoannah
2019-07-27 18:09:26potomaksetmessageid: <>
2019-07-27 18:09:26potomaklinkissue37496 messages
2019-07-27 18:09:25potomakcreate