PEP 649: distinguish annotations requested as strings vs objects (#3118)
This commit is contained in:
parent
076f44117a
commit
8c61071df1
12
pep-0649.rst
12
pep-0649.rst
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue