The reason it's not an option by default is because it would be the one case where the decorator would have to return a new class, and I didn't want to do that on the first version. As it is, @dataclass just modifies an existing class. I might bite the bullet add a slots option, and we've had discussions on adding a language feature to automatically add slots to a class, based on annotations and maybe some other magic. If we did that, we wouldn't need to return a new class. But it's not a front-burner task for me.
I really appreciate it! Only issue I see is that it won't support inherited dataclasses where the base class already defines __slots__, but I should be able to hack together support.
Maybe that would have worked better with a metaclass.
But still, I think not using a metaclass is the more flexible design. Maybe I'll add the "add_slots" behavior into the @dataclass decorator in 3.10, even though it would need to return a new class. At least it could be well documented, and I doubt it's a concern for most people.
> Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.
I'm offended! I also wrote f-strings, but maybe that's not considered new anymore. In any event, you're welcome!
Maybe the __slots__ discussion is not really that important - it's just convenience, and the regular old method of adding slots still works. So it's a minor thing.
I have diligently converted to f-strings but it doesn't give me new expressibility like I feel dataclasses do, just convenience :)
FYI if you haven't heard of it, attrs (https://www.attrs.org/en/stable/) is a package very similar to dataclasses that does support aromatically adding __slots__. I believe dataclasses was bases on it.
Yes, attrs is the spiritual parent of dataclasses, including the decision to not use metaclasses. Thanks for mentioning this: I try to always give credit to Hynek and attrs.
