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 <pbr...@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. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AP6TJNGH5SKFX3H5EL2QWACYG3F7WQF7/ Code of Conduct: http://python.org/psf/codeofconduct/
