Typecheck `dataclasses.replace` semantically

[thejcannon]

Is your feature request related to a problem? Please describe.

import dataclasses

@dataclasses.dataclass
class Bar:
    x: int = dataclasses.field()

bar = Bar(1)
dataclasses.replace(bar, x='')  # maybe should error?

Describe the solution you'd like
Ideally, a type error on the last line 😄

I understand it'd require special-casing dataclasses.replace, but I think the pros outweigh the cons.
(maybe https://discuss.python.org/t/generalize-replace-function/28511/14 would also help here?)

Additional context
I was testing if the provisional PEP 712 support did the right thing and found this. When/if this is fixed, mind checking on PEP 712 support? 😄

[tmke8]

Previously requested in #1047 but mypy recently added support for this so maybe the situation is different now: python/mypy#14849

[thejcannon]

Aye aye aye I shouldn't file issues late at night. I forgot to search for a possible closed one 😅

I tried this on mypy and didn't get an error so I'm surprised to hear mypy supports it.

There's also https://discuss.python.org/t/generalize-replace-function/28511/16 which might shake things up for better

[AlexWaygood]

I tried this on mypy and didn't get an error so I'm surprised to hear mypy supports it.

Did you try using the mypy master branch? The merged PR @tmke8 linked to hasn't appeared in any release of mypy yet (it'll probably be included in mypy 1.5.0).

[thejcannon]

hasn't appeared in any release of mypy yet

Ah that'd do it.

[erictraut]

We generally don't override the type information provided in typeshed with special-case logic. Doing so is not scalable in general, and it tends to lead to problems as typeshed stubs and the type system evolve. There have been only a couple of cases where we've decided to special case functionality for stdlib types. This (very short) list includes functools.partial and functools.total_ordering. We decided in these cases to support special casing because they were leading to significant false positive errors, there was no viable workaround, and we received strong signal from pyright users (in the form of a large number of upvotes) that these were pain points.

The dataclasses.replace doesn't meet any of these criteria. It's not leading to any false positive errors. There is an obvious (as well as terser and easier-to-read) workaround that supports full type validation (bar.x = ""). And we've received no other requests from pyright users so far.

I'm therefore going to close this feature request for now. It's something we could revisit in the future if there's sufficient signal from pyright users. Keep in mind that the bar for special-casing specific functions within pyright is very high.

[kyle-query]

Dunno if this helps anyone, but I have worked around this with some boilerplate:

import dataclasses
from typing import TypedDict
from typing_extensions import Unpack

class BarReplaceable(TypedDict, total=False):
    x: int

@dataclasses.dataclass
class Bar:
    x: int

    def replace(self, **updates: Unpack[BarReplaceable]) -> "Bar":
        return dataclasses.replace(self, **updates)

This gives a type-safe wrapper around dataclasses.replace. It works on a small scale, but will be tedious with more than a handful of dataclasses.

I tried to skip the boilerplate with something like this. Unfortunately it requires callers to pass every single attribute because P.kwargs behaves like a TypeDict with total=True. You might as well just call your constructor and pass all the parameters in at that point.:

import dataclasses
from typing import Callable, ParamSpec, TypeVar, TYPE_CHECKING

if TYPE_CHECKING:
    from _typeshed import DataclassInstance
else:
    DataclassInstance = object

T = TypeVar("T", bound=DataclassInstance)
P = ParamSpec("P")

def replace(constructor: Callable[P, T], obj: T, *args: P.args, **kwargs: P.kwargs) -> T:
    return dataclasses.replace(obj, **kwargs)

@dataclasses.dataclass
class Bar:
    x: int
    y: int

bar = Bar(x=1, y=1)

replace(Bar, bar, x=0) # => argument missing for parameter y

[ericrbg-harmonic]

There is an obvious (as well as terser and easier-to-read) workaround that supports full type validation (bar.x = "").

Just a small comment that this isn't always the case; for frozen dataclasses, you can't do this.