From 0cd7acd5a3aed2baa3cfcc20c5af944788214a81 Mon Sep 17 00:00:00 2001 From: Chris Angelico Date: Mon, 1 Nov 2021 11:48:09 +1100 Subject: [PATCH] PEP 671: Update to latest implementation --- pep-0671.rst | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/pep-0671.rst b/pep-0671.rst index b85e56168..ed6d0139c 100644 --- a/pep-0671.rst +++ b/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 connect(timeout=>default_timeout): 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, 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 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 -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 selfref(spam=>spam): # SyntaxError - def frob(n=>len(items), items=[]): # SyntaxError + def spaminate(sausage=>eggs + 1, eggs=>sausage - 1): # Error + def selfref(spam=>spam): # Error + def frob(n=>len(items), items=[]): # Error 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)): 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. @@ -127,17 +132,10 @@ used as dictionary lookup keys, where PEP 671 does not apply. Open Issues =========== -- yield/await? Will they cause problems? Might end up being a non-issue. - -- annotations? They go before the default, so is there any way an anno could - want to end with ``=>``? - -- 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. +- 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, + a default, or both. The worst offender is the ``:=`` notation, as ``:int=`` + would be a valid annotation and early-bound default. 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 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 -----