The definition there can’t fully sidestep an LSP issue. all types are subtypes of object, so the definition of __class__ there is a problem with the current definitions, as even protocols have to be compatible with object’s definitions.
I’m slowly[1] making progress on a better set of type definitions and specification language for type and object, as well as “acceptable types” for all methods and attributes defined by python’s data model, but there’s some ugly cases where subtyping relation alone won’t be enough without forbidding certain things. A prior thread on Hashability and Equality covers some of the more obvious issues, but accurately modeling __class__ within the type system is a particularly interesting issue as well.
As far as I’m concerned, that definition currently has undefined behavior because that protocol requires ignoring a conflict with the current definition of object.__class__, and could cease working at any time or not work in one typechecker while working in another.
No ETA, this is something I’m working on as I have the energy and time to, it’s not a pressing concern or a blocker for anything at my day job, etc. ↩︎