What would you expect get_type_hints(...) to return with relaxed syntax? Today, for type hint annotations, it returns a type, which I'd argue is an important feature to preserve (in it or some successor).

On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote:
On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan <pbryan@anode.ca> wrote:
I favour annotations for type hints; the writing's been on the wall for some time. I think the necessary escape hatch for those using it for other purposes should be Annotated[Any, ...] (or a similar, nicer alternative).

Guido, one of the difficulties I'm having is understanding the direction you're going with "relaxed syntax". PEP 649 is concrete; it's hard to weigh its merits against the usability—even feasibility—of incorporating an as yet undefined relaxed syntax.

At the end of the day, such syntax is going to have to be represented in some structure. If one were to accept that annotations are for type hints only, is the debate then the difference between a Python type (which PEP 649 would yield) and some other as yet undefined structure? 

In `__annotations__` it would be a string, as currently implemented in the 3.10 alpha code. The string just might not be parsable as an expression.

In the AST, it will have to be a new node that just collects tokens and bracketed things; that could be an array of low-level tokens.