gh-135228: Create __dict__ and __weakref__ descriptors for object

[encukou]

Here's another possible way to solve #135228:
The __dict__ and __weakref__ descriptors don't really need to hold a strong reference to "their" type; they are generic and could be created for object instead.
Here's a proof of concept. A cleaner way to do this would be creating the descriptor objects once and caching them in the interpreter state.

This does involve a behaviour change -- before:

>>>classC: pass>>>C.__dict__['__dict__'] <attribute'__dict__'of'C'objects>>>>C.__dict__['__dict__'].__objclass__<class'__main__.C'>

After:

>>> class C: pass >>> C.__dict__['__dict__'] <attribute '__dict__' of 'object' objects> >>> C.__dict__['__dict__'].__objclass__ <class 'object'> 

• Issue: 3.14 regression: slot dataclasses classes leak original class #135228

[encukou]

I can polish this, but I think it'd be better to target 3.15, and follow through a bit more.
The descriptor objects themselves could be shared across all classes that need them (within an interpreter), but it's not as straightforward to plug that into the type creation machinery.

[encukou]

Here's a polished version: the descriptors are made for type, which means thet skip type-checking (they work on any object). The getter/setter functions already check if their argument has a __dict__/__weakref__.

And since they're the same for all objects, they can be shared across all types in an interpreter -- that is, cached in interpreter state.

[encukou]

This now partially reverts #137047. I don't think keeping sys._clear_type_descriptors is worth it. If removed, power users can test its presence to see whether it's needed.

[JelleZijlstra]

Thanks, this is a nice improvement! I think there's risk this will break some advanced introspection code, similar to the change you had to make to inspect, but if it goes in early in the 3.15 cycle, that should be OK.

[serhiy-storchaka]

I suggest to wait some time, maybe until 3.14.1, so we can have chance to get some feedback about an alternate approach and decide whether it is worth to backport this approach to 3.14. We may also find completely different solution of the original problem in 3.15.

[encukou]

I suggest to wait some time [before backporting]

Definitely! Personally, I don't think this should be backported at all. (But I wouldn't have backported #137047 to a RC either if that was up to me...)