Chris Angelico writes:
On Sat, Dec 11, 2021 at 5:35 PM Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
foo(x=>[a])
I'm not sure what that last line would mean.
This isn't about your proposal, it's about more general syntax. Not everything being discussed is about your proposal, and I suspect one reason you have trouble figuring out what other people are talking about is that you persistently try to force everything into that context.
My proposal doesn't change the call site in any way, so I'm trying to figure out what you mean by that call. Are you saying that x=>[a] would be an assignment statement that sets x to an unevaluated expression?
No, I'm saying it would be an assignment expression (like :=), but that's what it would do. But that binding would be ignored, and the value passed into the function in the usual way. A keyword argument would be set with the even uglier x = (x=>[a]).
If so, that's independent of the default argument.
Of course it is, because it's a device to pass a general "deferred object" which is constructed in the actual argument list.
If it's a special way to pass keyword arguments to a function,
No. In fact in this context x is a dummy, as ugly as any crash test dummy after the crash. I probably should have used _.
It would also require significant changes to the way that nonlocal names are looked up (or would be restricted in what nonlocals it can refer to, possibly none at all).
All of which should clue you in that that's probably not what I'm talking about, especially when I explicitly wrote "while in an executable context, it could return the object, as := does".
Indeed. But here's the question: If a deferred object is to be a replacement for default_factory, then it must by definition be able to be stored for later. So it can't be autoevaluated unless there's some mechanism for delaying the autoevaluation. This seems like an incredibly messy approach.
Such an object is not evaluated when created; it's evaluated when referenced, like a descriptor. Descriptors are messy, too, but very useful.
The use-cases for deferred evaluation differ
Yup. It's an object, those use-cases can "almost certainly" (IMHO, but I suspect David and Eric agree) be distinguished by attributes set on the object, or auxiliary APIs for special use-cases where you want the unevaluated object. I suspect that most folks who want "deferred objects" haven't really thought about this issue, but have focused on their immediate applications.
What would have overlap with argument defaults isn't the same thing that would be useful for dataclasses.
If you say so, but forgive me if I table your comment and wait for Eric to weigh in on requirements related to dataclasses. In any case, if the default is such a deferred object x, I'm pretty sure that doing x=x before entering the function body is equivalent to your proposal. I see no particular reason why we couldn't have that rule for "deferred objects" created in "function signature scope". Steve