Giovanni Cappellotto <potoma...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37496> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
