On 1/11/21 3:02 PM, Paul Bryan wrote:
PEP 563 does go on to state:
For code which uses annotations for other purposes, a regular
eval(ann, globals, locals) call is enough to resolve the annotation.
And I believe this would no longer be true under PEP 649; further,
localns (and maybe globalns) parameters in get_type_hints would become
meaningless.
[...]
And, would get_type_hints continue evaluate [string] annotations in
that case?
I don't work on typing.get_type_hints() so someone else will have to
answer this question. All I can say is, with PEP 649 semantics, if you
set an annotation to a string, you'll get a string back. And in 3.9
(and my out-of-date 3.10) I observe that typing.get_type_hints() will
eval() string annotations for you, and localns is significant.
This passage in PEP 563 appears not true in Python 3.9 with __future__
annotations, emphasis mine:
The get_type_hints() function automatically resolves the correct
value of globalns for functions and classes. *It also automatically
provides the correct localns for classes.*
If this passage was true, I believe the issue that resulted in my
affixing type hints could have been averted.
As you've discovered, this is one of the places where PEP 563 seems to
be out-of-date with respect to its implementation. I sifted through the
source code to typing.get_type_hints() twice, and near as I can figure
out, localns is literally only ever set to None unless you override it
with the parameter.
OK, would string representations of type hints continue be supported
under PEP 649 if strings are used as annotations?
PEP 649 is itself totally agnostic as to what value you use as an
annotation. It disallows a couple funky things (yield, walrus
operator), but beyond that it doesn't care. Any Python expression or
value is fine.
*2. __co_annotations__ scope?*
I'm wondering why __co_annotations__ function could not be scoped
(within a closure?) such that it can access the values where the
function, method, class or module are being declared? I acknowledge
that I'm railing against PEP 563 again, trying to reclaim lost ground.
This is addressed in PEP 563, when it rejected the idea of using
"function local state when defining annotations":
I wasn't thinking the function local state of that being annotated
(agree, this would be prohibitive), but rather the scope in which the
annotated function, class, module, etc. are being defined.
That's what PEP 563 is referring to. If you read the thread from
November 2017 where the idea was discussed, they were talking about
referring to e.g. "class-level definitions", as in, things defined
inside class scope. Which is prohibitive.
(If I understand you correctly, you thought it was referring to the
scope inside the function when it runs? Because I can't imagine how
that would ever work. What if the function hasn't been called yet?
What if it's been called a thousand times? What if it's running right
now in various stages of completeness in five threads and you inspect
the annotation from a sixth thread?)
Cheers,
//arry/
_______________________________________________
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/UZOL6QXEZI5PXEHYMRNBEXY4W4N5OTFA/
Code of Conduct: http://python.org/psf/codeofconduct/
