Skip to content

3.13 Better Document __replace__ on Dataclasses and Named Tuples #121371

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

Open
max-muoto opened this issue Jul 4, 2024 · 2 comments
Open

3.13 Better Document __replace__ on Dataclasses and Named Tuples #121371

max-muoto opened this issue Jul 4, 2024 · 2 comments
Labels
docs Documentation in the Doc dir

Comments

@max-muoto
Copy link
Contributor

Documentation

With named tuples and dataclasses now implementing __replace__, it would be good to have some clearer documentation on this somewhere. Type-checkers will likely have to implement support as a specific implementation detail, which MyPy is already starting to do (see here, for example), so having more formal documentation of this fact would helpful.

@max-muoto max-muoto added the docs Documentation in the Doc dir label Jul 4, 2024
@serhiy-storchaka
Copy link
Member

The __replace__ method itself is an implementation detail. Only the support of copy.replace() should be documented. In future we may add other ways to specify this.

Special methods like __iter__ or __reduce__ are rarely documented. Instead the fact that objects are iterable or pickleable are documented.

@max-muoto
Copy link
Contributor Author

The __replace__ method itself is an implementation detail. Only the support of copy.replace() should be documented. In future we may add other ways to specify this.

Special methods like __iter__ or __reduce__ are rarely documented. Instead the fact that objects are iterable or pickleable are documented.

Makes sense, I will just say it just being documented in copy, while it needing to be special-cased I think makes it harder to realize that type-checkers should likely implement support - so I do wonder if there's a better way to indicate things like that long-term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

No branches or pull requests

2 participants