Add @disjoint_base (PEP 800)

[JelleZijlstra]

python/peps#4505

[AlexWaygood]

🚀

[AlexWaygood]

would it not be better to protect this with a try/except block, similar to what we do with typing.final? https://github.com/python/cpython/blob/9a21df7c0a494e2819775eabd522ebec994d96c0/Lib/typing.py#L2677-L2684

Most solid bases from the standard library will not permit you to set this attribute:

>>> int.__solid_base__ = True
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    int.__solid_base__ = True
    ^^^^^^^^^^^^^^^^^^
TypeError: cannot set '__solid_base__' attribute of immutable type 'int'

And you might plausibly write a metaclass to make class objects immutable even if a class is written in pure Python -- I don't think you should have to avoid adding this decorator (which exists primarily to help out static type checkers) just because the class is immutable at runtime

[JelleZijlstra]

I did it that way in @final because we added the dunder attribute later and didn't want to break compatibility. Other more recently added decorators such as @deprecated and @dataclass_transform don't have the try-except.

Not necessarily opposed to adding the try-except though.

[AlexWaygood]

yeah, it just seems sort-of odd to set it unconditionally, given that most pre-existing solid bases without __slots__ would not allow you to set the attribute. And it also seems more likely than usual that you might try to make a pure-Python class might be immutable if you're adding the solid_base decorator to it

[AlexWaygood]

I still don't see any harm in being more cautious about trying to set the attribute, and I think it has some benefits, so I'd still prefer protecting it in a try/except block. But I'm also happy with this being landed as-is if you disagree :-)