I'd recommend putting all this in a try-except in case we break this trick in a later version of CPython; if so, it feels better for your users to leak the original class than to get a mysterious error about mappingproxies.

@JelleZijlstra given context from Discord, we’re kinda weighting “broken introspection” vs “things explode if someone adds another decorator at the wrong position” anyways?

Yes, this variant definitely has some questionable edge cases. I think you can be a bit less conservative in CPython in terms of judging whether this hack is worth it.

As I understand from Brandt, a problem with the hack is that it mutates the class dict without incrementing the internal version tag for the type object. A workaround could then be to perform some no-op that increments the version tag anyway. For example, setting cls.__abstractmethods__ to its existing value could work.

I think you can be a bit less conservative in CPython in terms of judging whether this hack is worth it.

I'm afraid we have to be more conservative, because in attrs slots are on by default. :|

But looking again at the code, which part is actually dangerous here? It's just the wekreaf part, no? We do not modify self._cls.__dict__ – we just use your escape hatch to break cycles.

E.g. I tried this:

def test_no_references_to_original_when_using_cached_property(self):
        """
        When subclassing a slotted class and using cached property, there are
        no stray references to the original class.
        """

        @attr.s(slots=True)
        class C:
            pass

        tmp = None

        def decorator(cls):
            nonlocal tmp
            tmp = cls
            return cls

        @attr.s(slots=True)
        @decorator
        class C2(C):
            @functools.cached_property
            def value(self) -> int:
                return 0

        print(tmp.__dict__)

        # The original C2 is in a reference cycle, so force a collect:
        gc.collect()

        print(tmp.__dict__)

        assert [C2] == C.__subclasses__()

and it obviously fails, because there's a legit reference to the original class within tmp. But both prints work and print what would be expected without segfaulting.

Doesn't this mean that the only downside/edge case (aside from it potentially breaking eventually) is that the original class can't be weakref'ed? I'm not super deep in this topic, so happy to be enlightened. That would def be a downside I'd be OK to accept.

No, the risky part is removing "__dict__" from the __dict__. The interpreter uses various caches and optimizations that are keyed on the "type version", a number that gets incremented when the type is modified. Because we use this trick to get to the type dict (which usually can't be modified directly from Python code), we're modifying the type dict without bumping the version number. That can lead to crashes if interpreter code assumes the dict is unchanged from before.

There is a separate risk that you break users of the original class who rely on the __dict__/__weakref__ slots. But that is Python-level breakage (things throw exceptions), not C-level breakage (the interpreter crashes).

A bit more color on what exactly this breaks on the affected class (the original class that we want to be garbage collected):

• Removing __weakref__ actually breaks very little that matters. Even after the slot is deleted, weakref.ref() still works on these objects. It's just the Python-visible obj.__weakref__ attribute that is gone, but as far as I can tell basically nothing relies on that.
• Removing __dict__ means that obj.__dict__ no longer works, but direct attribute access (obj.x = 1) still works.

@JelleZijlstra so __abstractmethods__ didn't work, because it's not omnipresent – will this work too?

No, modifying the name doesn't bump the type version. I think if there's no __abstractmethods__, you can set it to a nonempty value and then del it.

better now @JelleZijlstra? i have to admit i'm fishing a bit in the dark here

This looks like it should work! Note this is still technically unsafe in the presence of threading: if somebody in another thread interacts with the class while you are doing this, things may explode.