
On 8/11/2021 11:07 AM, Jukka Lehtosalo wrote:
On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger <tagrain@gmail.com <mailto:tagrain@gmail.com>> wrote:
Would: ``` @dataclass class Node: global_node: __class__ | None ```
"Just work" with co_annotations?
This feels too specialized to me.
It would be great to also handle forward references to other classes and cyclic references, which are also somewhat common:
@dataclass class NodeA: component: NodeB | None
@dataclass class NodeB: component: NodeA | None
Note that for dataclasses itself, you can just use: @dataclass class NodeA: component: "NodeB | None" @dataclass class NodeB: component: "NodeA | None" It's only looking for typing.ClassVar or dataclasses.InitVar. Anything else, including a string, just means "this is a normal field". This will result in dataclasses.fields(NodeA)[0].type being the string "NodeB | None". But that's okay with dataclasses. However, there are a number of open bpo issues where people want dataclasses to resolve the .type value to be the actual type object instead of a string, especially if using 'from __future__ import annotations'. I guess dataclasses.fields() could assist there, optionally. Eric
Another, slightly more complex example would be cyclic references within two modules in an import cycle. For example, NodeA and NodeB could be defined in different modules. The common thing is that the dependency cycle can only be fully resolved after we have created both type objects. The import cycle case is probably less common but I've seen it in real-world code.