On Sun, Dec 12, 2021 at 4:06 AM Christopher Barker <pythonchb@gmail.com> wrote:

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):

If I'm not mistaken, dataclasses generate __init__ using exec anyway, so this would work with a plain string. ChrisA

Christopher Barker writes:

This suggestion would mean that “=>” would create a deferred expression, but it would not be a general purpose one.

I would prefer that "=>" create a general purpose evaluation-deferred expression, but that the general-purpose one be tuned such that you don't need new syntax to dereference it in the common use cases. This generality might be implemented by a "context" attribute on the object, or as Eric suggests it might be a rule that "deferred objects" that are defined as default function arguments get evaluated before the function body (ie, as in PEP 671, I think).

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.

There is some such facility in Common Lisp, so I think this is quite feasible. There will be a lot of bikeshedding to be done about *which* namespaces deserve the simplest syntax in *which* contexts. Eg, I don't think there will be much disagreement about evaluating "deferred objects" used as argument defaults just before the function body is entered using the namespaces used in PEP 671, but the case of an actual argument that is a "deferred object" probably would be more contentious.

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.

I don't think this works very well. At the very least, some effort should go into thinking about potential generalization and reserving some names in the class namespace so that all the good names don't get taken by early user-derived classes. I'm not sure this is a good example, but consider the case of Decimal which has a lot of good properties from the point of view of "naive" user expectations about numerical computations. Unfortunately it was late enough to the party that it's not vary attractive unless you actually grok floating point; newbies are just going to use floats. Of course Decimal has all the same kind of traps as float, but they're far more familiar. People expect 1/3 to result in an approximately equal value; they do not expect 1/5 to do so. I wonder if making Decimal the default for decimal literals wouldn't be a good deal, but I guess I'm gonna have to wonder forever. :-) [1] Footnotes: [1] *Not* intended as a suggestion.

On Sun, Dec 12, 2021 at 4:06 AM Christopher Barker <pythonchb@gmail.com> wrote:

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):

If I'm not mistaken, dataclasses generate __init__ using exec anyway, so this would work with a plain string. ChrisA

Christopher Barker writes:

This suggestion would mean that “=>” would create a deferred expression, but it would not be a general purpose one.

I would prefer that "=>" create a general purpose evaluation-deferred expression, but that the general-purpose one be tuned such that you don't need new syntax to dereference it in the common use cases. This generality might be implemented by a "context" attribute on the object, or as Eric suggests it might be a rule that "deferred objects" that are defined as default function arguments get evaluated before the function body (ie, as in PEP 671, I think).

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.

There is some such facility in Common Lisp, so I think this is quite feasible. There will be a lot of bikeshedding to be done about *which* namespaces deserve the simplest syntax in *which* contexts. Eg, I don't think there will be much disagreement about evaluating "deferred objects" used as argument defaults just before the function body is entered using the namespaces used in PEP 671, but the case of an actual argument that is a "deferred object" probably would be more contentious.

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.

I don't think this works very well. At the very least, some effort should go into thinking about potential generalization and reserving some names in the class namespace so that all the good names don't get taken by early user-derived classes. I'm not sure this is a good example, but consider the case of Decimal which has a lot of good properties from the point of view of "naive" user expectations about numerical computations. Unfortunately it was late enough to the party that it's not vary attractive unless you actually grok floating point; newbies are just going to use floats. Of course Decimal has all the same kind of traps as float, but they're far more familiar. People expect 1/3 to result in an approximately equal value; they do not expect 1/5 to do so. I wonder if making Decimal the default for decimal literals wouldn't be a good deal, but I guess I'm gonna have to wonder forever. :-) [1] Footnotes: [1] *Not* intended as a suggestion.