PEP 671: Update to latest implementation
This commit is contained in:
parent
5c9ce152a1
commit
0cd7acd5a3
32
pep-0671.rst
32
pep-0671.rst
|
@ -60,6 +60,7 @@ Function default arguments can be defined using the new ``=>`` notation::
|
||||||
def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
|
def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
|
||||||
def connect(timeout=>default_timeout):
|
def connect(timeout=>default_timeout):
|
||||||
def add_item(item, target=>[]):
|
def add_item(item, target=>[]):
|
||||||
|
def format_time(fmt, time_t=>time.time()):
|
||||||
|
|
||||||
The expression is saved in its source code form for the purpose of inspection,
|
The expression is saved in its source code form for the purpose of inspection,
|
||||||
and bytecode to evaluate it is prepended to the function's body.
|
and bytecode to evaluate it is prepended to the function's body.
|
||||||
|
@ -71,11 +72,13 @@ allows the expression to refer to other arguments.
|
||||||
Multiple late-bound arguments are evaluated from left to right, and can refer
|
Multiple late-bound arguments are evaluated from left to right, and can refer
|
||||||
to previously-defined values. Order is defined by the function, regardless of
|
to previously-defined values. Order is defined by the function, regardless of
|
||||||
the order in which keyword arguments may be passed. Using names of other
|
the order in which keyword arguments may be passed. Using names of other
|
||||||
arguments is a SyntaxError at function definition time::
|
arguments is an error. It is implementation-defined whether this is a syntax
|
||||||
|
error or a run-time error, and implementations are free to be more permissive,
|
||||||
|
but this should not be relied upon.
|
||||||
|
|
||||||
def spaminate(sausage=>eggs + 1, eggs=>sausage - 1): # SyntaxError
|
def spaminate(sausage=>eggs + 1, eggs=>sausage - 1): # Error
|
||||||
def selfref(spam=>spam): # SyntaxError
|
def selfref(spam=>spam): # Error
|
||||||
def frob(n=>len(items), items=[]): # SyntaxError
|
def frob(n=>len(items), items=[]): # Error
|
||||||
|
|
||||||
|
|
||||||
Choice of spelling
|
Choice of spelling
|
||||||
|
@ -86,11 +89,13 @@ Our chief syntax proposal is ``name=>expression`` -- our two syntax proposals
|
||||||
|
|
||||||
def bisect(a, hi=>len(a)):
|
def bisect(a, hi=>len(a)):
|
||||||
def bisect(a, hi=:len(a)):
|
def bisect(a, hi=:len(a)):
|
||||||
|
def bisect(a, hi:=len(a)):
|
||||||
def bisect(a, hi?=len(a)):
|
def bisect(a, hi?=len(a)):
|
||||||
def bisect(a, hi!=len(a)):
|
def bisect(a, hi!=len(a)):
|
||||||
def bisect(a, hi=\len(a)):
|
def bisect(a, hi=\len(a)):
|
||||||
def bisect(a, hi=`len(a)`):
|
def bisect(a, hi=`len(a)`):
|
||||||
def bisect(a, hi=@len(a)):
|
def bisect(a, hi=@len(a)):
|
||||||
|
def bisect(a, @hi=len(a)):
|
||||||
|
|
||||||
Since default arguments behave largely the same whether they're early or late
|
Since default arguments behave largely the same whether they're early or late
|
||||||
bound, the preferred syntax is very similar to the existing early-bind syntax.
|
bound, the preferred syntax is very similar to the existing early-bind syntax.
|
||||||
|
@ -127,17 +132,10 @@ used as dictionary lookup keys, where PEP 671 does not apply.
|
||||||
Open Issues
|
Open Issues
|
||||||
===========
|
===========
|
||||||
|
|
||||||
- yield/await? Will they cause problems? Might end up being a non-issue.
|
- Annotations go before the default, so in all syntax options, it must be
|
||||||
|
unambiguous (both to the human and the parser) whether this is an annotation,
|
||||||
- annotations? They go before the default, so is there any way an anno could
|
a default, or both. The worst offender is the ``:=`` notation, as ``:int=``
|
||||||
want to end with ``=>``?
|
would be a valid annotation and early-bound default.
|
||||||
|
|
||||||
- Rather than banning future refs, these could be permitted, at the price of
|
|
||||||
harder-to-explain semantics. Arguments would be resolved first with those
|
|
||||||
passed and those with early-bound defaults, and then late-bound ones would
|
|
||||||
be evaluated, left-to-right; the consequences for getting it wrong would
|
|
||||||
then be UnboundLocalError at call time, rather than SyntaxError from the
|
|
||||||
function definition.
|
|
||||||
|
|
||||||
|
|
||||||
Implementation details
|
Implementation details
|
||||||
|
@ -163,6 +161,10 @@ function will begin with the parameter unbound. The function begins by testing
|
||||||
for each parameter with a late-bound default, and if unbound, evaluates the
|
for each parameter with a late-bound default, and if unbound, evaluates the
|
||||||
original expression.
|
original expression.
|
||||||
|
|
||||||
|
Out-of-order variable references are permitted as long as the referent has a
|
||||||
|
value from an argument or early-bound default.
|
||||||
|
|
||||||
|
|
||||||
Costs
|
Costs
|
||||||
-----
|
-----
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue