I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression.
To be honest, the most pressing issue with annotations is the clumsy way that type variables have to be introduced. The current convention, `T = TypeVar('T')`, is both verbose (why do I have to repeat the name?) and widely misunderstood (many help request for mypy and pyright follow from users making a mistaken association between two type variables that are unrelated but share the same TypeVar definition). And relaxed annotation syntax alone doesn't solve this.
Nevertheless I think that it's time to accept that annotations are for types -- the intention of PEP 3107 was to experiment with different syntax and semantics for types, and that experiment has resulted in the successful adoption of a specific syntax for types that is wildly successful.
On Sun, Apr 11, 2021 at 7:02 PM Larry Hastings firstname.lastname@example.org wrote:
Attached is my second draft of PEP 649. The PEP and the prototype have both seen a marked improvement since round 1 in January; PEP 649 now allows annotations to refer to any variable they could see under stock semantics:
- Local variables in the current function scope or in enclosing
function scopes become closures and use LOAD_DEFER.
- Class variables in the current class scope are made available using
a new mechanism, in which the class dict is attached to the bound annotation function, then loaded into f_locals when the annotation function is run. Thus permitting LOAD_NAME opcodes to function normally.
I look forward to your comments,
*/arry* _______________________________________________ Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/QSASX6PZ... Code of Conduct: http://python.org/psf/codeofconduct/