Chris Angelico writes: > On Sat, Dec 11, 2021 at 5:35 PM Stephen J. Turnbull > <stephenjturnb...@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 _______________________________________________ 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/LCMG3JZLBNY45CWH6YNVLAW2EYIOXBFD/ Code of Conduct: http://python.org/psf/codeofconduct/
