
Steven D'Aprano writes:
I don't think that's what PEP 563 says. Annotations are not *restricted* to only be strings, it is merely that when the function or class object is built, the annotations are left as strings.
You're right, I was imprecise. I meant as PEP 563 is implemented now, I doubt it can handle non-strings nicely.
So we can post-process annotations and destringify them:
True, but you face the dread "double-decode problem": if the annotation happens to destringify to a string, then the "post- processor" may try to destringify again. I guess we can mark each annotation as already destringified or not. As long as this is done by some sort of API, you're probably OK (but it makes me nervous since __annotations__ is completely exposed to the program, as in your example).
There may be scoping issues to be sorted out, but I don't think they are insurmountable.
But isn't there still the issue of forward reference, which motivates these PEPs in the first place?