Dataclasses without `__init__` no longer work in 3.14.1 due to #137711

[emontnemery]

Bug report

Bug description:

The resolution for #137530, #137711 which was backported to 3.14 and included in 3.14.1, breaks dataclasses without __init__.
Although a dataclass without __init__ doesn't seem that helpful, it doesn't seem to be explicitly forbidden and shouldn't break in a point release.

from dataclasses import dataclass, field

@dataclass(slots=True, init=False)
class MyClass:
 attr: int

 def __new__(cls, attr: int) -> Self:
 self.attr = attr
 return self

Error message:

$ python3 dataclasses_issue.py
Traceback (most recent call last):
 File "/home/erik/dataclasses_issue.py", line 3, in <module>
 @dataclass(slots=True, init=False)
 ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/erik/.pyenv/versions/3.14.1/lib/python3.14/dataclasses.py", line 1426, in wrap
 return _process_class(cls, init, repr, eq, order, unsafe_hash,
 frozen, match_args, kw_only, slots,
 weakref_slot)
 File "/home/erik/.pyenv/versions/3.14.1/lib/python3.14/dataclasses.py", line 1234, in _process_class
 cls = _add_slots(cls, frozen, weakref_slot, fields)
 File "/home/erik/.pyenv/versions/3.14.1/lib/python3.14/dataclasses.py", line 1401, in _add_slots
 init_annotate = newcls.__init__.__annotate__
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'wrapper_descriptor' object has no attribute '__annotate__'. Did you mean: '__getstate__'?

CPython versions tested on:

3.14.1

Operating systems tested on:

Linux

Linked PRs

• gh-142214: Fix two regressions in dataclasses #142223
• [3.14] gh-142214: Fix two regressions in dataclasses (GH-142223) #142277

[dpinol]

as an example, it breaks networkx 3.6

 File "/usr/local/lib/python3.14/site-packages/networkx/utils/configs.py", line 8, in <module>
 @dataclass(init=False, eq=False, slots=True, kw_only=True, match_args=False)
 ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.14/dataclasses.py", line 1426, in wrap
 return _process_class(cls, init, repr, eq, order, unsafe_hash,
 frozen, match_args, kw_only, slots,
 weakref_slot)
 File "/usr/local/lib/python3.14/dataclasses.py", line 1234, in _process_class
 cls = _add_slots(cls, frozen, weakref_slot, fields)
 File "/usr/local/lib/python3.14/dataclasses.py", line 1401, in _add_slots
 init_annotate = newcls.__init__.__annotate__
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'wrapper_descriptor' object has no attribute '__annotate__'. Did you mean: '__getstate__'?

[Giuzzilla]

Python 3.14.1 is breaking my sqlalchemy-based project as well, seems related to the issue/dataclasses, stacktrace:

mypackage/mymodel.py:109: in <module>
 class MyModel(Base, kw_only=True):
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_api.py:626: in __init_subclass__
 super().__init_subclass__(**kw)
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_api.py:846: in __init_subclass__
 _as_declarative(cls._sa_registry, cls, cls.__dict__)
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_base.py:245: in _as_declarative
 return _MapperConfig.setup_mapping(registry, cls, dict_, None, {})
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_base.py:326: in setup_mapping
 return _ClassScanMapperConfig(
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_base.py:564: in __init__
 self._setup_dataclasses_transforms()
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_base.py:1171: in _setup_dataclasses_transforms
 self._apply_dataclasses_to_any_class(
.venv/lib/python3.14/site-packages/sqlalchemy/orm/decl_base.py:1227: in _apply_dataclasses_to_any_class
 dataclass_callable( # type: ignore[call-overload]
/usr/local/lib/python3.14/dataclasses.py:1436: in dataclass
 return wrap(cls)
 ^^^^^^^^^
/usr/local/lib/python3.14/dataclasses.py:1426: in wrap
 return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/local/lib/python3.14/dataclasses.py:1217: in _process_class
 text_sig = str(inspect.signature(
/usr/local/lib/python3.14/inspect.py:3321: in signature
 return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
/usr/local/lib/python3.14/inspect.py:3036: in from_callable
 return _signature_from_callable(obj, sigcls=cls,
/usr/local/lib/python3.14/inspect.py:2557: in _signature_from_callable
 return _get_signature_of(init)
 ^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/lib/python3.14/inspect.py:2440: in _signature_from_callable
 sig = _get_signature_of(obj.__func__)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/lib/python3.14/inspect.py:2511: in _signature_from_callable
 return _signature_from_function(sigcls, obj,
/usr/local/lib/python3.14/inspect.py:2334: in _signature_from_function
 annotations = get_annotations(func, globals=globals, locals=locals, eval_str=eval_str,
/usr/local/lib/python3.14/annotationlib.py:973: in get_annotations
 ann = _get_and_call_annotate(obj, format)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/lib/python3.14/annotationlib.py:1112: in _get_and_call_annotate
 ann = call_annotate_function(annotate, format, owner=obj)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/lib/python3.14/annotationlib.py:711: in call_annotate_function
 return annotate(format)
 ^^^^^^^^^^^^^^^^
/usr/local/lib/python3.14/dataclasses.py:553: in __annotate__
 new_annotations[k] = cls_annotations[k]
 ^^^^^^^^^^^^^^^^^^
E KeyError: 'my_field'

[pareshjoshij]

Looks like we're seeing two different side effects from the recent annotation updates.

1 The NetworkX crash: It seems init=False exposes object.init (a wrapper descriptor), which naturally lacks annotate.

2 The SQLAlchemy KeyError: It looks like the code assumes every field must exist in cls_annotations. That assumption might be too strict for dynamic classes where attributes are injected.

I suspect adding guards in both spots to handle missing attributes/keys would fix this?

[sobolevn]

Also got this error today: https://github.com/wemake-services/django-modern-rest/actions/runs/19889091191/job/57003155723

[pareshjoshij]

@epenet that link speaks volumes.

The fact that they had to rush that merge to unblock CI—even skipping the documentation steps you suggested—really confirms how severe the instability is for downstream users.