Hi Erik, On Fri, Mar 4, 2022 at 4:04 PM Erik De Bonte <Erik.DeBonte@microsoft.com> wrote:
Eric Traut suggested to me that in addition to your suggestion, we should change transform_descriptor_types to mean that *all* fields are treated as class variables, rather than just having special treatment for descriptor fields. We'd rename transform_descriptor_types to something else if we made this change of course. Maybe class_variable_fields or class_variables.
That's interesting. It seems more consistent/principled, which I like, but I don't have an immediate intuition about the practical usefulness. In the common case of `x: int` this would make no difference; that always describes an instance variable. Similarly for `x: int = 3` which always describes an instance variable with default, and `x: ClassVar[int] = 3`, which always describes a class variable (and thus should be excluded from the dataclass transform.) It seems like the cases where it would make a difference are descriptor types and the interpretation of `Final` (i.e. whether or not `x: Final[int] = 3` implies `ClassVar`) -- are there other cases where it would matter? As long as the descriptor behavior is consistent as described in my last mail, I guess I don't have strong feelings for or against this extended proposal. I think it will be hard to name well. A name including `class_variable(s)` is potentially misleading, as it seems to imply all attributes are implicitly ClassVar or something, which is not the case. The real distinction is a bit subtle and we don't have a good term for it. Something like `assume_instance_level_annotations=False` maybe.
Maybe this should be something you specify in a field descriptor rather than globally for the entire dataclass?
That's a reasonable suggestion. However, we're not aware of any libraries requiring per-field control of this behavior. And if we only support this behavior via field descriptors (not class-wide), I believe it will make life more awkward for libraries -- they wouldn't want users to need to set this parameter explicitly, so it would need to be inferred via overloads.
That makes sense. I retract that suggestion; this is something that should be defined by the library providing dataclass-like behavior (since that library will be providing the actual runtime behavior), not by the end user of the library. Carl