Add copy.replace for 3.13

[max-muoto]

Add copy.replace which is new in 3.13: https://docs.python.org/3.13/library/copy.html#copy.replace

[max-muoto]

See us mostly using += in most places with __all__, guessing this is for better static analysis support, or something like that?

[JelleZijlstra]

Yes, this is fine, it's so we don't have to repeat the whole list for every version.

[max-muoto]

Oh, I meant versus using append.

[JelleZijlstra]

Except it actually isn't in __all__: https://github.com/python/cpython/blob/89bf33732fd53fbb954aa088cfb34f13264746ad/Lib/copy.py#L59 . So we shouldn't add it in the stub either.

This may be an oversight, so consider opening an issue over on CPython for adding replace to copy.__all__. But as long as it's not there at runtime, we shouldn't add it in the stub either.

[max-muoto]

My bad, let me fix that.

[max-muoto]

775e88b

[max-muoto]

Higher-kinded types could be cool here, but obviously no way to get great kwargs type-checking. Even in that case you can't use P.kwargs without P.args.

[max-muoto]

Some classes are missing __replace__ dunders but will tackle that separately.

[max-muoto]

Interestingly, Pyright is fine with this example, and MpPy is not (causing the test failure):

from __future__ import annotations
from typing import Self, Protocol, ClassVar
import copy


class ReplaceableClass:
    def __init__(self, val: int) -> None:
        self.val = val

    def __replace__(self, val: int) -> Self:
        cpy = copy.copy(self)
        cpy.val = val
        return cpy


from collections.abc import Callable


class _SupportsReplace(Protocol):
    __replace__: Callable[..., Self]



def foo(sr: _SupportsReplace) -> None:
    ...

foo(ReplaceableClass(23))

Would you consider this a MyPy bug @JelleZijlstra?

[max-muoto]

Interestingly, Pyright is fine with this example, and MpPy is not (causing the test failure):

from __future__ import annotations
from typing import Self, Protocol, ClassVar
import copy


class ReplaceableClass:
    def __init__(self, val: int) -> None:
        self.val = val

    def __replace__(self, val: int) -> Self:
        cpy = copy.copy(self)
        cpy.val = val
        return cpy


from collections.abc import Callable


class _SupportsReplace(Protocol):
    __replace__: Callable[..., Self]



def foo(sr: _SupportsReplace) -> None:
    ...

foo(ReplaceableClass(23))

Would you consider this a MyPy bug @JelleZijlstra?

Using paramspec is a workaround that works for both: 58bb691

[erictraut]

I think there's a problem with the way you defined the _SupportsReplace protocol. You're defining __replace__ as an instance variable.

I recommend changing it to:

class _SupportsReplace(Protocol):
    def __replace__(self, *args: Any, **kwargs: Any) -> Self:
        ...

Mypy works fine if you define it this way.

[max-muoto]

I think there's a problem with the way you defined the _SupportsReplace protocol. You're defining __replace__ as an instance variable.

I recommend changing it to:

class _SupportsReplace(Protocol):
    def __replace__(self, *args: Any, **kwargs: Any) -> Self:
        ...

Mypy works fine if you define it this way.

Thanks, I think I thought originally this wouldn't work since it doesn't work if you leave out *args with Pyright.

Fixed: 860f674

[max-muoto]

Added replace to __all__ based on python/cpython@7c66906

[JelleZijlstra]

CI will fail for now since it's not in __all__ in the last beta. We can either wait for the next beta or merge this without __all__ for now (which would be my preference).

[picnixz]

Technically speaking, it does support positionals, but those will be passed as keywords. What it does not support however is positional-only arguments.

On the other hand, you can just force people to use keyword-only arguments so that it matches https://docs.python.org/3.13/library/copy.html#object.__replace__. Or at least, make self a positional-only argument.

[max-muoto]

On the other hand, you can just force people to use keyword-only arguments so that it matches

The only issue is that won't work that way you might think with either MyPy or Pyright. Take this example: https://pyright-play.net/?pythonVersion=3.13&strict=true&code=GYJw9gtgBALgngBwJYDsDmUkQWEMoAK4MYAxmADYA0UAginAFDOkUCGAzh1APoDKAVwQ48HAEoBTBO1ISAFETAlyFAJQAuRlG1QAJhOC8eIKTIk8ecjhIrAaAKnsBrAO5sQaDuroNVUALQAfFAAcmAoEt4AdDHMjKyc3ACS2BSaOnoGRibSbLIWVjZ2UO5oPACM3qgwfkGh4ZFQMVHM%2BoYwEhwwcjkybABGFI38QiIw4qZ5ErXBYRHRscxY0lAAvFAp0nKqjB1dcstqQA

[JelleZijlstra]

Yes, callables with *args: Any, **kwargs: Any are treated specially in the spec.

[picnixz]

Some classes are missing __replace__ dunders but will tackle that separately.

We just added __replace__ on AST nodes (it's not in 3.13) in case you're interested in adding it for 3.14 only.

[max-muoto]

Some classes are missing __replace__ dunders but will tackle that separately.

We just added __replace__ on AST nodes (it's not in 3.13) in case you're interested in adding it for 3.14 only.

My guess is we'll get around this once we start running stubtest on 3.14.

[JelleZijlstra]

Yes, callables with *args: Any, **kwargs: Any are treated specially in the spec.

[max-muoto]

@JelleZijlstra It looks like we're running against beta 4 now, do we want to merge this to resolve the CI failure?

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[JelleZijlstra]

Sure. Seems like there's some other unrelated new stubtest failures too.