Is it possible to create covariant frozen dataclasses in 3.13

[dmontagu]

I just noticed that when using pyright in python 3.13 mode, all of my frozen dataclass generic variable variance inference was returning invariant, whereas in all previous versions it worked as expected.

After some digging, I discovered that it seems this is due to the introduction of __replace__, as discussed in this issue python/mypy#17623 and this thread https://discuss.python.org/t/make-replace-stop-interfering-with-variance-inference/96092/20.

This is really unfortunate, I'm writing some code for a typesafe control flow graph library in pydantic/pydantic-ai#2982 and it relies heavily on generics and variance behavior, and it's rather unfortunate if I can't use dataclasses anywhere if I want type-checking compatibility with python 3.13.

I suppose I could replace the infer_variance=True with use of covariant=True etc. in typevars, but variance inference has actually been very helpful while developing this — there's enough surface area that it's easy to miss a place where variance soundness was broken.

Is there any way to work around this new limitation for variance inference for frozen dataclasses today (or expected to be in the near future)? (E.g., something like explicitly setting __replace__ = None on the class, though I tried that specifically and it didn't work.) If not, I suppose I'll drop the use of dataclasses throughout the code I'm adding but I'd really rather not do that. But it's a hard requirement that the variance is correct for the relevant classes, and I very strongly prefer to be able to rely on variance inference because it's so easy to make mistakes. (Not to mention, in the future when we can use the new syntax from PEP695, we'll be able to drop all the explicit typevar creation.)

[dmontagu]

I understand the problems with ignoring __replace__, but would it be possible (/practical, I guess) to disable the generation of the __replace__ method during type-checking (and avoid the ensuing variance inference consequences) if you set __replace__ = None on a dataclass?

[decorator-factory]

Another solution could be synthesizing a generic __replace__. Something like this:

@dataclass(frozen=True)
class Box[A]:
    name: str
    value: A

    # *synthesized*
    @overload
    def __replace__(self, *, name: str = ...) -> Box[A]:
        ...

    @overload
    def __replace__[B](self, *, name: str = ..., value: B) -> Box[B]:
        ...

But from what I understand, for N type variables this currently requires 2**N overloads, since setting a default like [B = A] is not allowed

[erictraut]

Moving to discussion since this isn't really an enhancement request.

Prior to making any change in pyright related to this topic, we need to bottom out on a solution in the community forum. We need someone to drive the discussion to a conclusion, propose a change in the typing spec, and shepherd it through the TC approval process. I don't think this would require a full PEP.

[dmontagu]

My workaround for now is to change the dataclass definition from the following:

from dataclasses import dataclass
from typing import Generic

from typing_extensions import TypeVar

T = TypeVar('T', infer_variance=False)

@dataclass(frozen=True)
class MyDC(Generic[T]):
    x: T
    """Description of x."""

to

@dataclass(init=False)
class MyDC(Generic[T]):
    _x: T
    """Description of x."""

    @property
    def x(self) -> T:
        return self._x

    def __init__(self, x: T):
        self._x = x

Doing this private-attribute+property dance for all fields that reference generic parameters. This achieves the typing I want and at least saves me from needing to copy/paste the __repr__ definition. Looking forward to a better workaround at some point.

[oliver-batchelor]

Also running into exactly the same issue here.