-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
bpo-46534: Implement PEP 673 Self in typing.py #30924
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
Conversation
Tests were copied from typing_extensions Co-authored-by: Pradeep Kumar Srinivasan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your work! 👍
Misc/NEWS.d/next/Library/2022-01-26-18-06-08.bpo-46534.vhzUM4.rst
Outdated
Show resolved
Hide resolved
Did you mean to push some changes? Doesn't look like our comments were addressed. |
Sorry my bad. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The runtime behavior LGTM. If Jelle and Nikita (and anyone else interested) are happy with the docs I'll merge. Personally I think the docs are very clear too.
Thank you for implementing this James!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks again! 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally still find the documentation a little sparse, and would love to see more of the stuff from PEP 673 included in the typing
module documentation. (It was a really great PEP! Extremely clear and informative, really nicely written — kudos 😀)
Nonetheless, the documentation you've added here looks great, and more can always be added in future PRs.
Congrats on the PEP being accepted! I'm super excited to start using this feature :)
Co-authored-by: Jelle Zijlstra <[email protected]>
Should an entry be added to "What's New in Python 3.11"? |
Yes. |
Should that be done in this PR? I thought the what's new was collated manually later. I assume typing.reveal_type() and friends should also get what's new entries. |
What's New entries can be added at any time, and often are edited in a later stage. But there's absolutely no rule that says you can't add one at the same time you change the code! We've had a tradition of not requiring What's New for a few reasons: devs writing code aren't always good at writing docs, and vice versa; and sometimes What's New needs to be reorganized to make it more readable for users who want to quickly know what's changed. We especially want to avoid that What's New reads like a Changelog file -- we have the Misc/NEWS entries for that (those can still be edited but it rarely happens unless there are blatant errors, and the goal there is to be complete, just not as detailed as "git log" output). So it's up to you. |
Thanks Guido! For my function PRs, I'd rather add a single PR summarizing all of them in What's New once we have decided on each of the PRs. I'm also happy to add a What's New entry for PEP 673 in that case. So I think this PR is ready to merge. |
Misc/NEWS.d/next/Library/2022-01-26-18-06-08.bpo-46534.vhzUM4.rst
Outdated
Show resolved
Hide resolved
@gvanrossum I think this can be merged now; Alex, Nikita, and I approved it. I'll work on What's New for typing in 3.11 once my other PRs are resolved. |
Let's see how the tests fare (tip: when the tests aren't run because the PR submitter is new to the project, ask a core dev to run the tests). |
Everything is green here now. |
Doc/library/typing.rst
Outdated
This annotation is semantically equivalent to using a :class:`TypeVar` with ``bound=Foo`` as | ||
both the return annotation and the annotation for the ``self`` parameter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if instead of this complicated sentence we should just show the code (with a comment saying something like "don't do this, do the other thing").
Maybe also explain how this is similar and different than
class Foo:
def return_self(self) -> "Foo":
...
Misc/NEWS.d/next/Library/2022-01-26-18-06-08.bpo-46534.vhzUM4.rst
Outdated
Show resolved
Hide resolved
Misc/NEWS.d/next/Library/2022-01-26-18-06-08.bpo-46534.vhzUM4.rst
Outdated
Show resolved
Hide resolved
Thanks a lot for this @Gobot1234 and @pradeep90! And thanks Jelle for sponsoring. |
Thank you to everyone that reviewed this. |
https://bugs.python.org/issue46534
CC @pradeep90 & @JelleZijlstra