On 8/11/2021 11:07 AM, Jukka Lehtosalo wrote:
On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger <tagr...@gmail.com
<mailto:tagr...@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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7GU6PYY2JDAY52FQ3ZXYJN3RDZS4RN5N/
Code of Conduct: http://python.org/psf/codeofconduct/
