3.14 regression: slot dataclasses classes leak original class

[Tinche]

Bug report

Bug description:

While trying to test cattrs on 3.14 I ran into this issue. Here's a simple reproducer that passes on 3.13, but doesn't on 3.14.

import gc
from dataclasses import dataclass


@dataclass(slots=True)
class B:
 b: int


gc.collect()

assert [
 o for o in gc.get_objects() if hasattr(o, "__name__") and o.__name__ == "B"
] == [B]

Originally I ran into this issue with slotted attrs classes but the core problem is the same. Since slotness cannot be added to a class, dataclasses and attrs classes create a class copy with slots instead. The old class used to hang around until a GC collection happened (guess there are some reference cycles, but I never investigated thoroughly).

On 3.14, a full GC collection does not clean up the original class, causing a leak. Apart from leaking, in case of subclassing the original class will remain in the list of the parent .__subclasses__(), causing an issue.

CPython versions tested on:

3.14

Operating systems tested on:

macOS

Linked PRs

• gh-135228: Break reference cycle between class and descriptors #135230
• gh-135228: When @dataclass(slots=True) replaces a dataclass, make the original class collectible #136893
• [3.14] gh-135228: When @dataclass(slots=True) replaces a dataclass, make the original class collectible (GH-136893) #136960
• gh-135228: Create __dict__ and __weakref__ descriptors for object #136966
• [3.14] Revert "[3.14] gh-135228: When @dataclass(slots=True) replaces… #137013
• Revert "gh-135228: When @dataclass(slots=True) replaces a dataclass, make the original class collectible (#136893)" #137014
• gh-135228: When @dataclass(slots=True) replaces a dataclass, make the original class collectible (take 2) #137047
• [3.14] gh-135228: When @dataclass(slots=True) replaces a dataclass, make the original class collectible (take 2) (GH-137047) #137666
• gh-105936: Properly update closure cells for __setattr__ and __delattr__ in frozen dataclasses with slots #144021

[JelleZijlstra]

I think this is because the annotate function for the class holds on to the original class namespace, and that namespace dict contains the descriptors B.__dict__ and B.__weakref__ that refer back to the original class. Not too sure how to fix that yet.

[JelleZijlstra]

This seems hard to avoid, maybe we should just live with the change? The reason is that the annotation scope needs to hold a reference to the actual class dict (for reasons explained in https://jellezijlstra.github.io/pep695#class-scopes) and the class dict contains two descriptors, for __dict__ and __weakref__, that contain references back to the class object.

In Python 3.12 and 3.13 this behavior is already observable if you use a type alias or TypeVar bound in the dataclass, with one of these class definitions:

@dataclass(slots=True)
class B:
 def f[T: int](self, x: T) -> T: ...
 b: int

@dataclass(slots=True)
class B:
 type T = int
 b: int

Both of these fail the assertion in the post above.

I put up a change in #135230 that fixes this issue, but messing with the descriptors feels like it's probably going to break something else.

[Tinche]

@JelleZijlstra I think you're right that the leak itself is not a big deal, and we can just live with it.

What is a bigger deal is this:

from dataclasses import dataclass


class A:
 pass


@dataclass(slots=True)
class B(A):
 pass


print(A.__subclasses__()) # [<class '__main__.B'>, <class '__main__.B'>]

This will break a piece of cattrs and anyone using __subclasses__() with slotted dataclasses and attrs classes. Maybe we can work around it in the __subclassess__() implementation somehow?

[gpshead]

release blocker status just to help force consideration. It may wind up deferred.