-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
GH-87390: Add remaining tests for PEP 646 #98267
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
PS. You can use `breakpoint()` instead of that. :-)
Oops, good catch - I think I must have accidentally committed my debug changes, because I found some other things that needed removing. Have fixed them and confirmed that CI is actually passing now :) |
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! Just a few small things.
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'm mostly relying on Jelle's keen eye here. This will have to miss 3.11.0 but will be in 3.11.1.
For variadic cases, these tests should be regarded as the source of truth, | ||
since we hadn't realised the full complexity of variadic substitution | ||
at the time of finalizing PEP 646. For full discussion, see |
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.
If the SC doesn't object maybe we could update the PEP with a more exact specification? Since this was discovered during the beta test period it makes sense to me to update the PEP. Storing a part of a specification permanently in an issue seems iffy to me (plenty of tests refer to the issue that caused the test to be added, but the wording here makes me think that the situation here is different -- this is effectively part of the specification).
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.
Sure - if the SC is fine with it, I'd be happy to write this up in the PEP properly.
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.
@mrahtz From the SC issue I gather the following:
- We should add these tests (they'll land in 3.11.1, that's fine)
- We (you) should write the PEP update and submit it to the SC for formal approval
I expect the SC approval for the PEP updates should be easy to obtain.
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.
Ok, great. I'll work on the PEP updates as soon as I have some time.
@JelleZijlstra Are you happy with these tests? Then you can merge them. |
Probably, I'll take another look tonight and merge if I'm happy. |
Thanks @mrahtz for the PR, and @JelleZijlstra for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, @mrahtz and @JelleZijlstra, I could not cleanly backport this to |
Co-authored-by: Guido van Rossum <[email protected]>. (cherry picked from commit cb95cc2) Co-authored-by: Matthew Rahtz <[email protected]>
GH-98667 is a backport of this pull request to the 3.11 branch. |
Co-authored-by: Guido van Rossum <[email protected]>. Co-authored-by: Matthew Rahtz <[email protected]> (cherry picked from commit cb95cc2)
This PR fixes the last few things from the PEP 646 implementation checklist at #87390 (comment). Specifically:
test_genericalias.py
before the star-unpacking grammar change was merged[tuple[*Ts, T][str, *tuple[int, ...]]
)typing.py
for*
ed stuff (again, now that the grammar change is merged)get_origin
on unpacked stuffA couple notes:
tuple, Tuple
and*, Unpack
, for a total of 4 versions of each test, but that would be reeeaaally verbose, so I've gone with just testing the 'new-style' cases (*
andtuple
) and the 'old-style' cases (Unpack
andTuple
).get_origin
currently gives different behaviour for*tuple[int]
andUnpack[tuple[int]]
:tuple
in the former case,Unpack
in the latter. This is a bit inconsistent, but it seems like the least surprising thing from a user's perspective: if I sawUnpack[something]
, I'd intuitively expected the origin to beUnpack
; and if I saw*tuple[something]
, I'd expect the origin to betuple
.