Use ~~dataclasses~~ attrs for pt.Array

[kaushikcfd]

Pros:

• Immutable types (frozen=True)
• Derived classes can be dataclasses (noticed while implementing Functions #364)
• In almost all cases uses the generated __init__.

Cons:

• All derived classes must do eq=False in their call to dataclass, otherwise dataclasses will implement its own default which has a complexity of $O(2^N)$ in number of nodes in the DAG.
• All derived classes must do def __hash__(self) -> int: return super().__hash__(), otherwise dataclasses will implement its own default.
• Constructor arguments have to be _shape, _dtype instead of shape, dtype as pt.Array already has properties of that name.
• ⚠️ Pylint Failures.

[inducer]

This generally seems worthwhile, I think.

• All derived classes must do eq=False in their call to dataclass, otherwise dataclasses will implement its own default which has a complexity of O(2N) in number of nodes in the DAG.
• All derived classes must do def __hash__(self) -> int: return super().__hash__(), otherwise dataclasses will implement its own default.

Is this something we could check for in __post_init__ in __debug__ mode?

pylint

Ah well. Maybe just disable unexpected-keyword-arg for pylint?

[kaushikcfd]

Ah well. Maybe just disable unexpected-keyword-arg for pylint?

Yep, I will do that for now. Related pylint issue: pylint-dev/pylint#7623.

[kaushikcfd]

The pylint errors have been ignored. But the current refactoring depends on kw_only argument of dataclasses.field that was introduced in 3.10. Maybe we can merge this once we force the requirement to Py3.10?

[kaushikcfd]

Is this something we could check for in post_init in debug mode?

Yes, I think so. I will try to give it a shot.

[inducer]

The pylint errors have been ignored. But the current refactoring depends on kw_only argument of dataclasses.field that was introduced in 3.10. Maybe we can merge this once we force the requirement to Py3.10?

Is there a way to avoid that? Requiring 3.10 is a healthy ways down the road in my view, given that we're not even completely switched over to 3.8.

[kaushikcfd]

Is there a way to avoid that?

We could use attrs instead of dataclasses?

[inducer]

We could use attrs instead of dataclasses?

As long as it's easy enough to switch back to dataclasses, I would not be oppposed.

[kaushikcfd]

As long as it's easy enough to switch back to dataclasses, I would not be opposed.

Sure! It should take us an afternoon to switch to dataclasses from attrs.