[hugr-py] Avoid overriding __init__() for dataclasses?

[cqc-alec]

It is really nice (especially for debugging) to be able to reconstruct a Python object by directly evaluating its string __repr__(). If dataclasses are used "all the way down" then this is possible as long as the generated __init__() and __repr__() methods are preserved. However in hugr-py many of the __init__() methods are overridden; so for example if I have a Hugr h:

In [71]: repr(h)
Out[71]: 'Hugr(root=Node(0), _nodes=[NodeData(op=DFG(inputs=[Bool]), parent=None), NodeData(op=Input(types=[Bool]), parent=Node(0)), NodeData(op=Output(), parent=Node(0))], _links=BiMap({}), _free_nodes=[])'

In [72]: Hugr(root=Node(0), _nodes=[NodeData(op=DFG(inputs=[Bool]), parent=None), NodeData(op=Input(t
    ...: ypes=[Bool]), parent=Node(0)), NodeData(op=Output(), parent=Node(0))], _links=BiMap({}), _fr
    ...: ee_nodes=[])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[72], line 1
----> 1 Hugr(root=Node(0), _nodes=[NodeData(op=DFG(inputs=[Bool]), parent=None), NodeData(op=Input(types=[Bool]), parent=Node(0)), NodeData(op=Output(), parent=Node(0))], _links=BiMap({}), _free_nodes=[])

TypeError: Hugr.__init__() got an unexpected keyword argument 'root'

I wonder if we could replace the overriding __init__() methods with classmethods that do the same job.

[ss2165]

We override init for one main reason: ensure the created object is valid. Not using init as the primary means of construction wouldn't be very pythonic.

Secondly, I think to achieve what you suggest we'd also have to leave repr untouched, which we override often to produce easier to read prints, with reduced verbosity. This is especially useful for types.

[cqc-alec]

We override init for one main reason: ensure the created object is valid. Not using init as the primary means of construction wouldn't be very pythonic.

Fair point.

Secondly, I think to achieve what you suggest we'd also have to leave repr untouched, which we override often to produce easier to read prints, with reduced verbosity. This is especially useful for types.

We could use __str__() for this purpose -- __repr__() is intended to be unambiguous while __str__() is intended to be human-readable (and is used by print()).

So I guess I'd advocate for overriding __init__(), __repr__() and __str__(), the goal being that __str__() is readable and x == eval(repr(x)), if practical.

[nelimee]

Reading your discussion, you might be interested in the __post_init__ method provided by Python dataclasses that is systematically called just before returning from the auto-generated __init__ method and can be used to change/initialise non-fronzen dataclass attributes or validate that the provided attributes are indeed correct.

Also, Python documentation of repr explicitly list the goal mentioned above (eval(repr(obj)) is a valid instance):

Return a string containing a printable representation of an object. For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval(), otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object.

[cqc-alec]

Thanks, __post_init__ looks like it could solve the issue in cases where we want to initialize with a subset of the dataclass members (and compute the others from them). I'm not sure if this covers all our use cases for overriding __init__(), but might be made to work with some coercion.

[ss2165]

__repr__() is intended to be unambiguous while __str__() is intended to be human-readable

yes I did think about this and chose __repr__ because that is what is used by the REPL when you evaluate an expression. So without overriding __repr__ all the documentation examples gain extremely verbose outputs. You start having to rely on assert equalities to expected results rather than visually seeing what it is you've just made.