On 2021-10-24 11:23, Chris Angelico wrote:
Ah, but is it ALL argument defaults, or only those that are
late-evaluated? Either way, it's going to be inconsistent with itself
and harder to explain. That's what led me to change my mind.
I don't understand what this means. The ones that are early-evaluated
were already evaluated at function definition time.
From the PEP:
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=>[]):
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.
To me that last part clearly indicates the way things should go. They
should go exactly like they currently go with the `if arg is None`
idiom. The code that gets prepended to the beginning of the function
should be exactly equivalent (or as exactly as something can be
equivalent to pseudocode :-) to:
for arg in arglist:
if arg is_undefined:
arg = eval(late_evaluated_default)
Arguments that don't have any kind of default won't reach this stage,
because the function should fail with a TypeError (missing argument)
before even getting to evaluating late-bound arguments. Arguments that
have early-bound defaults also won't reach this stage, because they
can't be "undefined" --- either a value was passed, or the early-bound
default was used.
A strict left-to-right evaluation order seems by far the easiest to
explain, and easily allows for the kind of mutually-referential cases
under discussion. If the only problem is that UnboundLocalError is a
weird error, well, that's a small price to pay. If possible it would be
nice to detect if the UnboundLocalError was referring to another
late-bound argument in the signature and give a nicer error message.
But UnboundLocalError makes more sense than SyntaxError for sure.
Of course, as I said, I don't support this proposal at all, but I
appear to be in the minority on that, and if does go through I think it
would be even worse if it raises SyntaxError.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GR3PL6H2WYZ4BAJ4T6LDKVVS6J6FMCGN/
Code of Conduct: http://python.org/psf/codeofconduct/
