On Sat, Dec 11, 2021 at 8:07 PM Stephen J. Turnbull <stephenjturnb...@gmail.com> wrote: > > 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.
Yes, it's silly of me to think of everything in a PEP 671 thread as if it's about argument defaults. Carrying on. The reason I thought it might be about arg defaults is that you did also show an arg default in the exact same block. That kinda sullies the waters a bit. Actually, a lot. If you want to talk about deferred expressions, can you restrict it to one example rather than two? It's hard to parse, especially with all the one-letter names. > > 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]). uhhh.... I'm lost. Are you saying that "x=>" is a magic token that doesn't actually assign to x, but it just means that the thing that follows it is a deferred expression? If so, why not a keyword like "defer"? > > 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". What's an executable context though? I don't understand. > > 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. How? > > 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". I *really* don't like that idea. If you want to propose that kind of thing, where it magically changes when you look at it, then go ahead, but that has nothing whatsoever to do with PEP 671, as it doesn't answer the same use-cases, is largely orthogonal, can be better explained without argument defaults being involved at all, and happens at the call site rather than the function signature. If I'm understanding your proposal correctly, using one of these deferreds as an argument default would look like "def f(x=x=>[]):", which, as well as being weirdly ugly, wouldn't even be incompatible with the proposal I'm making. ChrisA _______________________________________________ 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/LK5VSKOLSEH5N6JI2IVZSCNQH53E4UJF/ Code of Conduct: http://python.org/psf/codeofconduct/
