Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have namedtuple __replace__ return Self #17475

Merged

Conversation

max-muoto
Copy link
Contributor

@max-muoto max-muoto commented Jul 3, 2024

Have __replace__ for named tuples return Self to ensure protocol compatibility with copy.replace in the typeshed, and to be accurate to the actual dunder.

@max-muoto max-muoto changed the title Have nametupled __replace__ return self Have namedtuple __replace__ return self Jul 3, 2024
@max-muoto max-muoto changed the title Have namedtuple __replace__ return self Have namedtuple __replace__ return Self Jul 3, 2024

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

github-actions bot commented Jul 3, 2024

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅


replaced_2 = GenericA(x=0).__replace__(x=1)
reveal_type(replaced_2) # N: Revealed type is "__main__.GenericA"
GenericA(x=0).__replace__(x="abc") # E: Argument "x" to "__replace__" of "GenericA" has incompatible type "str"; expected "int"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's specialized, but the generic isn't in the revealed type which is odd.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's how mypy generally works:

% mypy -c 'x: list[str] = []; x.append(1)'
<string>:1: error: Argument 1 to "append" of "list" has incompatible type "int"; expected "str"  [arg-type]

Agree this is potentially confusing but it's not something that should be changed in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see, makes sense - let me bring this out of draft in that case.

@max-muoto max-muoto marked this pull request as ready for review July 3, 2024 17:35
@JelleZijlstra JelleZijlstra merged commit 1882ed7 into python:master Jul 3, 2024
18 checks passed
@ilevkivskyi
Copy link
Member

I am sorry but I am going to revert this. Even if it does fix something, this is a very wrong way to do fix it.

@max-muoto
Copy link
Contributor Author

I am sorry but I am going to revert this. Even if it does fix something, this is a very wrong way to do fix it.

Apologies there. How would you recommend going about fixing this in that case?

@ilevkivskyi
Copy link
Member

How would you recommend going about fixing this in that case?

For starter, it would be great to open an issue with a (detailed) explanation of what is wrong.

@max-muoto
Copy link
Contributor Author

max-muoto commented Jul 6, 2024

How would you recommend going about fixing this in that case?

For starter, it would be great to open an issue with a (detailed) explanation of what is wrong.

Sure thing - in short summary it replaces to how copy.replace is handled in 3.13, and the need for __replace__ to match a protocol which implements def __replace(self, *args: Any, **kwargs: Any) -> Self: ... but let me write something up (think this issue, but for named-tuples).

Issue: #17497

ilevkivskyi added a commit that referenced this pull request Jul 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants