Follow up / review necessity of `attrs`, as highlighted in [1-23]

[philtweir]

Feedback:

what I really don't like about the current approach is that the interface is tightly coupled to a third party library and I wonder if this can be relaxed using builtin Python functions/modules (typeddicts, namedtuples, dataclasses, etc.) and then provide support for attrs, dataclasses etc. on top of that? I.e. could one define a more generic interface?

[philtweir]

I'm inclined to believe that adding an abstraction layer for self-checking classes is unnecessary abstraction -- and I don't think having a third-party dependency is unreasonable practice in the Python ecosystem, if it provides a relevant improvement over standard library classes. However, there is a reasonable point that supporting dataclasses would be an intuitive and relevant addition and, in many cases, users may not be interested in or familiar with attrs.

As a compromise, dewret will take dataclasses as an alternative, but as two options, rather than a generalized abstraction layer. If that genuinely becomes too limiting in the future, then we can refactor.

[elleryames]

Closed by #14