Practically speaking, I'm not sure the __solid_base__ attribute will tell you much other than that the class was explicitly decorated with the @solid_base decorator. No builtin class will set the attribute, most external C extensions won't either, and any class that defines non-empty slots will be an implicit solid base even if it doesn't use the decorator. A class might also have a metaclass that prevents setting attributes, so not even all classes explicitly decorated with @solid_base will necessarily have this attribute set (python/typing_extensions#634 (comment)).

If we want third-party tools to be able to introspect a class's solid base at runtime, a better solution would probably be to add an inspect.get_solid_base introspection helper that does something similar to your logic in pycroscope. I don't think it's essential to add that as part of the PEP, though it might be useful.

Sure, but that doesn't seem too different from using the __final__ attribute: it doesn't actually stop you from creating subclasses, and there is no bool.__final__.

I think an inspect helper like that could be useful but don't feel a strong need for it myself.

My vague worry is that people will misunderstand this attribute and think that it's a reliable way of determining whether a class is a solid base or not. Unlike @final, it feels pretty unlikely that we'll see ever much usage of this decorator in .py files, so I'd expect the vast majority of solid bases not to have this attribute. (Though to be clear, I agree that it makes sense to make it possible to apply the decorator to classes in .py files.)

Still, you're right that there are lots of @final classes that also don't have the __final__ attribute. I suppose it's fine to make solid_base introspectable whenever it is used in .py files, and I suppose the __solid_base__ attribute no more misleading than the __final__ attribute set by @final