Every time I write a `class` statement in Python now, I wonder about this: https://blog.glyph.im/2023/02/data-classification.html
@glyph It most definitely does!
* Mixins
* Behavioural collections
* Dynamically constructed classes
Dataclasses are a special case, and most definitely should remain so.
@b11c you think mixins, behavioral collections, and dynamically constructed classes are *not* special cases?
@glyph Doesn't matter. If dataclasses are the default, then there needs to be some support for other use cases. But I can see a new "dataclass" keyword working.
@b11c are mixins even compatible with type annotations? and do dynamically constructed classes even use `class` statements? I don't really understand this criticism.
@glyph 1. Of course they are.
2. Generally no, but can be constructed from different types of classes, with and without attributes.
3. This is not a criticism, I'm just thinking about the common usages.
4. On reflection, I'm actually absolutely certain that dataclasses are a special case and not the other way around.
1. huh! I guess they do, you… put a bunch of `@abstractmethod`s on the mixin to say what it needs? I'll have to go fix up some legacy code to do that, at least, where I can't get rid of mixins entirely
2. what is the problem with constructing them from dataclasses, if they are constructed with regular classes?
3. if I'm saying "dataclasses are not a special case" and you are saying "dataclasses are a special case" it feels like definitionally a criticism?
4. agree to disagree 
@glyph 1. No, use Protocols.
@b11c I love me a good protocol, but where would you put it in a Mixin?
@glyph Option 1: In the mixin's inheritance tree, like in any other case.
Option 2: Nowhere. That's the beauty of protocols, you don't have to explicitly state it for a class to implement it.
@b11c mixins inherently require things from `self`, so if you do option 2 you get a bunch of type errors when you attempt to use it. but TIL inheriting a protocol in a semi-concrete class is functionally identical to declaring an `@abstractmethod` for all members of that protocol!
@b11c (I don't love the fact that you don't get type errors on any of this stuff until instantiation time, I feel like I really want to know what's concrete and what's abstract explicitly in the implementation. but it's a minor quibble.)