On Sat, Dec 11, 2021 at 9:26 AM Eric V. Smith <e...@trueblade.com> wrote: > > On 12/9/2021 10:32 AM, Eric V. Smith wrote: > > On 12/6/2021 1:24 AM, Christopher Barker wrote: > > > > But I honestly don’t get it. My idea of a deferred object would be quite > different that this, would not be a great replacement for this, and could > quite happily co-exist with this idea. Clearly I’m missing something. > > I've used this example before. > > Let's assume backticks create a "deferred object" (a name I hate, but I'll > continue to use in this discussion). I realize backticks won't fly, I'm using > them deliberately so as to not argue about the syntax here. > > If I want to specify a late bound dataclasses default parameter, currently I > have to say: > > @dataclasses.dataclass > class A: > my_list: list = dataclasses.field(default_factory=list) > > What I'd like to be able to say: > > @dataclasses.dataclass > class A: > my_list: list = `[]` > > In the class A, before @dataclass is called, I want A.my_list to be a > "deferred object" that I could then use when @dataclass is generating > __init__(). Exactly how and when the "deferred object" would get evaluated is > debatable, but not so important for the sake of this discussion. Suffice it > to say that it would either be explicitly or implicitly evaluated at the > start of __init__. > > I think you can see that this would benefit from similar functionality to > late-bound parameters, and that if we had this more general mechanism that > late-bound parameters could use the same underlying mechanism. > > And in case I wasn't clear: to get the late-bound parameter functionality > using this syntax, you'd use: > > def foo(my_list = `[]`): > > That's why I think we should have a larger concept that just late-bound > parameters: I think there's a general concept here that can be extended > beyond parameters. And that's why I thing not restricting it to a > function-definition-only syntax is important: we should produce a syntax that > can be used in more places than just functions. This is why I think we need > to decide on this larger scope before accepting the narrow > function-definition-only syntax: if we decide to add "deferred objects" > later, we'd have two ways to specify late-bound parameters [0]. >
It's larger than argument defaults, but also smaller: def bisect(a, hi=`len(a)`): Would this work by your theory? Remember that it must still be possible to pass a simple number (eg bisect(stuff, 5)), so the default needs to coalesce to an actual value immediately. The overlap with late-bound defaults is the simple case of mutable objects that you want to freshly construct every time, but ultimately, that's not hugely different from a lambda function: stuff = defaultdict(lambda: []) stuff = defaultdict(`[]`) The only difference might be that you could use isinstance to distinguish a deferred expression from some other sort of function. I'm not sure whether that would be significant enough for dataclasses to take advantage of. (Another theoretical difference is that a deferred expression is parsed in the context of its *usage* rather than its *definition*, but that would break all manner of things in Python and is quite impractical.) 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/C4E3UZRFUM7UHSFLX3JIUZJ57I7TCTRA/ Code of Conduct: http://python.org/psf/codeofconduct/
