PEP 649: distinguish annotations requested as strings vs objects (#3118)

This commit is contained in:
Carl Meyer 2023-04-22 23:51:09 -06:00 committed by GitHub
parent 076f44117a
commit 8c61071df1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 3 deletions

View File

@ -1080,12 +1080,13 @@ shortly.
Performance Comparison
======================
Performance with this PEP is generally favorable. There are three
Performance with this PEP is generally favorable. There are four
scenarios to consider:
* the runtime cost when annotations aren't defined,
* the runtime cost when annotations are defined but *not* referenced, and
* the runtime cost when annotations are defined *and* referenced.
* the runtime cost when annotations are defined and referenced as objects.
* the runtime cost when annotations are defined and referenced as strings.
We'll examine each of these scenarios in the context of all three
semantics for annotations: stock, :pep:`563`, and this PEP.
@ -1112,7 +1113,7 @@ being annotated:
class namespace or closure, this object will be a tuple constructed
at binding time.
When annotations are both defined and referenced, code using
When annotations are both defined and referenced as objects, code using
this PEP should be much faster than :pep:`563`, and be as fast
or faster than stock. :pep:`563` semantics requires invoking
``eval()`` for every value inside an annotations dict which is
@ -1121,6 +1122,11 @@ more efficient bytecode for class and module annotations than stock
semantics; for function annotations, this PEP and stock semantics
should be about the same speed.
The one case where this PEP will be noticeably slower than :pep:`563` is when
annotations are requested as strings; it's hard to beat "they are already
strings." But stringified annotations are intended for online documentation use
cases, where performance is less likely to be a key factor.
Memory use should also be comparable in all three scenarios across
all three semantic contexts. In the first and third scenarios,
memory usage should be roughly equivalent in all cases.