PEP 671: Since it keeps getting asked about, add a para on deferreds (#2661)
This commit is contained in:
parent
fa659f01c8
commit
13eed48c3c
12
pep-0671.rst
12
pep-0671.rst
|
@ -128,7 +128,7 @@ While this does not completely explain all the subtleties, it is sufficient to
|
|||
cover the important distinction here (and the fact that they are similar).
|
||||
|
||||
|
||||
Interaction with other open PEPs
|
||||
Interaction with other proposals
|
||||
================================
|
||||
|
||||
:pep:`661` attempts to solve one of the same problems as this does. It seeks to
|
||||
|
@ -141,6 +141,16 @@ of the common cases would no longer need sentinels if the true default could
|
|||
be defined by the function. Additionally, dedicated sentinel objects can be
|
||||
used as dictionary lookup keys, where :pep:`671` does not apply.
|
||||
|
||||
A generic system for deferred evaluation has been proposed at times (not to be
|
||||
confused with :pep:`563` and :pep:`649` which are specific to annotations).
|
||||
While it may seem, on the surface, that late-bound argument defaults are of a
|
||||
similar nature, they are in fact unrelated and orthogonal ideas, and both could
|
||||
be of value to the language. The acceptance or rejection of this proposal would
|
||||
not affect the viability of a deferred evaluation proposal, and vice versa. (A
|
||||
key difference between generalized deferred evaluation and argument defaults is
|
||||
that argument defaults will always and only be evaluated as the function begins
|
||||
executing, whereas deferred expressions would only be realized upon reference.)
|
||||
|
||||
|
||||
Implementation details
|
||||
======================
|
||||
|
|
Loading…
Reference in New Issue