I love using attrs, like the idea of bringing something similar to the standard library, but strongly disagree with the dataclasses API. It treats untyped Python as a second class citizen.
This is what I'd prefer
from dataclasses import dataclass, field
@dataclass
class MyClass:
x = field()
but it produces an error because fields need to be declared with a type annotation. This is the GvR recommended way to get around it:
@dataclass
class MyClass:
x: object
You could use the typing.Any type instead of object, but then you need to import a whole typing library to use untyped dataclasses. I highly prefer the former code block.
Yeah, it seems strange to force people to use type hints when it has had such a mixed reception. I really tried to use type hints with a new project a few months ago, but ended up stripping it all out again because it's just so damn ugly. I wish it were possible to fully define type hints in a separate file for linters, and not mix it in with production code. It's kind of possible to do it, but not fully [1], and mixing type hints inline and in separate files is in my opinion even worse than one or the other.
This is what I'd prefer
but it produces an error because fields need to be declared with a type annotation. This is the GvR recommended way to get around it: You could use the typing.Any type instead of object, but then you need to import a whole typing library to use untyped dataclasses. I highly prefer the former code block.There's a big thread discussing the issue on python-dev somewhere. Also some discussion in https://github.com/ericvsmith/dataclasses/issues/2#issuecomm...
Anyway, it's not a huge issue—attrs is great and there's no reason not to use it instead for untyped Python.