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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/FKOKFK7CPMMQEIPNZYJS56J3U3KFCFJE/ Code of Conduct: http://python.org/psf/codeofconduct/
