Thanks Carl! I'll modify the PEP to move the descriptor-typed field support to Rejected Ideas -- https://github.com/python/peps/pull/2477 FYI, while experimenting with the runtime behavior of dataclass, I noticed something weird about descriptor-typed fields and default values. It's more an issue for dataclass than dataclass_transform, but I thought it was worth mentioning. Here's the sample code you provided: ``` class Descriptor: def __get__(self, instance: Any, owner: object) -> int: return instance._x def __set__(self, instance: Any, value: float) -> None: instance._x = int(value) @dataclass class F: x: Descriptor = Descriptor() ``` Given that code, I believe that a type checker's view of F's __init__ would be: ``` def __init__(self, x: int = Descriptor()) ``` But this is incorrect since, as you pointed out, x doesn't have a default value at runtime. F() fails at runtime with "F.__init__() missing 1 required positional argument: 'x'" I also noticed that when executing the code for F, __get__ is called with a None instance, and surprisingly __get__'s return value in that case is used as the field's default value. So if I change __get__ to the following, F() succeeds and initializes x to 100. ``` def __get__(self, instance: Any, owner: object) -> int: if instance is None: return 100 return instance._x ``` I couldn't find this behavior documented anywhere though, and I wouldn't expect a type checker to analyze the code in __get__ to find this default value. So I'm not sure how type checkers should handle this situation. With dataclass_transform, the library author can make this scenario work by adding a "default" parameter on Descriptor's constructor and adding Descriptor to field_descriptors. But I'm not sure if there's a good solution for dataclass or if it's even worth fixing. -Erik