Add a new parameter to `@dataclass` to optionally turn off the synthesizing of a `__replace__` method

[tmke8]

Feature or enhancement

Proposal:

Most (all?) synthesized methods on dataclasses can be turned off:

• __init__ -> init=False
• __repr__ -> repr=False
• __eq__ -> eq=False
• __match_args__ -> match_args=False
• __slots__ -> slots=False
• __lt__(), __le__(), __gt__(), __ge__() -> order=False

But __replace__ cannot be turned off, which presents a problem for generic dataclasses: https://discuss.python.org/t/make-replace-stop-interfering-with-variance-inference/96092/

I propose this

@dataclass(replace=False)
class D:
    x: int

to create a dataclass without __replace__ method.

As far as I can tell, all that's needed is to put a guard around this line:

cpython/Lib/dataclasses.py

Line 1098 in a4709e5

_set_new_attribute(cls, '__replace__', _replace)

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

I proposed it in this comment on the DPO thread: https://discuss.python.org/t/make-replace-stop-interfering-with-variance-inference/96092/19

[serhiy-storchaka]

What about dataclasses.replace()? It will still work, right?

[tmke8]

Yes, `dataclasses.replace()` still would have the typing problem but the bigger problem is that currently all `TypeVar`s on dataclasses are inferred as invariant, even if one never uses `copy.replace()` or `dataclasses.replace()`. You are right that even with `replace=False` one can still use `dataclasses.replace()` which would be potentially unsafe from a typing perspective, but that seems like a problem to solve later. (For example linters could warn against the use of `dataclasses.replace()`.) It seems desirable to me to make `copy.replace()` behave safely from a typing perspective, regardless of what `dataclasses.replace()` is doing. It's actually really good that the `__replace__` protocol was added because now it's possible to individually decide which dataclasses should have the replace functionality and which shouldn't have. And we have found out that dataclasses shouldn't have this functionality if they want to have covariant type variables. So we can now handle this correctly. Oct 22, 2025 18:36:39 Serhiy Storchaka ***@***.***>:

…

    [Image]*serhiy-storchaka* left a comment (python/cpython#140457)[#140457 (comment)]    What about *dataclasses.replace()*? It will still work, right? — Reply to this email directly, view it on GitHub[#140457 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AB3B72P3YGDSNTF6454WRPL3Y6XBNAVCNFSM6AAAAACJ43USHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZTGI3DMOBUGM]. You are receiving this because you authored the thread. [Tracking image][https://github.com/notifications/beacon/AB3B72N6ROIMWPG7IWJGPR33Y6XBNA5CNFSM6AAAAACJ43USHCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWMUN7JW.gif]