Consider making DataclassLike non-final

[NeilGirdhar]

I want to derive a protocol from DataclassLike:

@runtime_checkable
class TDataclassInstance(DataclassLike, Protocol):
    static_fields: ClassVar[list[str]]
    dynamic_fields: ClassVar[list[str]]

This is for the return value of a dataclass_transform-marked constructor.

---

Another option would be to make final protocols support being inherited by other protocols, i.e., final only blocks non-protocol class inheritance.

[JelleZijlstra]

I'm not sure why we made it @final, and I'd probably support removing the decorator. Making a Protocol final feels kind of like going against the point of a Protocol.

[AlexWaygood]

The rationale for making it @final was that people might erroneously infer that they could create a dataclass by inheriting from DataclassLike, just as you can create an Iterator by inheriting from collections.abc.Iterator or create a pydantic model by inheriting from BaseModel. dataclasses works differently from all of those in that the library has decorator-based semantics rather than an inheritance-based model, and the idea was that it would be good to emphasise this fact, and thereby clarify what the protocol was for (just type hints, it doesn't have any runtime effect).

python/typing_extensions#115 (comment)

That rationale probably makes a lot more sense when it comes to adding this class to the stdlib than it does when it comes to adding it to this library; we're much less likely to get newbies here who don't know how to create a dataclass. But if the idea is that the things in this library are candidates for possible inclusion in the stdlib, then maybe we should try to keep things looking pretty much as they would if they were in the stdlib.

Anyway, wanting to extend the protocol is a good use case for making it no longer @final, so I'm okay with changing this here.