On Fri, Dec 10, 2021 at 7:54 PM Eric V. Smith wrote:

Not sure if you meant this to go to the list or not.

I did — ( I know it seems to be the consensus, but I really think respond to list should be the default…) Moving on… On 12/10/2021 7:50 PM, Christopher Barker wrote:

Thanks Eric, this is a great example, thanks.

It does raise some questions. Though.

If we could use any expression as a deferred expression, then we still have the two key questions:

When does it get evaluated, and what namespaces does it use?

I agree those are good questions. I think, like PEP 671, it would get evaluated at the start of the function (in this case, __init__). It's easier for dataclasses, because I could just force the evaluation there. But for normal function arguments, maybe we'd have to say that before the function starts executing, any arguments which are deferred objects automatically are evaluated. And I think the namespace would be where it's defined.

Ahh, then that would make them less useful for default parameters— even for the dataclass case. It would work fine if you used only builtins (or literals) but that’s about it. So Chris’ canonical example of n => len(input_list) wouldn’t work. Which is why I think that if there were a general purpose deferred object, we’d need special syntax or rules for when used as late-bound defaults. I'll admit I haven't thought all of this through in enough detail to

implement it. I'm just trying to point out that we could use the general concept in other places.

Which is exactly what I asked for — thanks! I think this is a really interesting use case, not so much as it’s a general purpose deferred object, but because it’s about how to do/use late-bound defaults in meta programming.

def fun(n): return `len(n)`

@dataclasses.dataclass class A: length: n = fun()

What would that put in the signature? What namespace would the express e evaluated in?

I think it should be evaluated in the context of "fun". Clearly it would need to create a closure.

Which would be a potentially useful deferred object, but not a good one for late-bound defaults. Here’s a new (not well thought out) idea: @dataclasses.dataclass class A: Input_list: list length: int => len(input_list) So length gets set to a “late bound default expression” that Is an actual value. It would have to store the expression itself, probably as a string, and it would get evaluated in the namespace of the function, when the function was called. So the generated __init__ would be the same as: def __init__(self, input_list, length=>len(input_list): And you could also do: get_length => len(input_list) @dataclasses.dataclass class A: Input_list: list length: int = get_length Not that that would be a good idea. This suggestion would mean that “=>” would create a deferred expression, but it would not be a general purpose one. Though maybe there could be a way to evaluate it in a more general way, kind of like eval — where you can control the namespaces used. I guess what I’m suggesting is that we could create a very specific kind of deferred object, and in the future expand it to more general use. Rather than the general case rendering the late-bound default concept. -CHB

-- Christopher Barker, PhD (Chris)

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython