Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-138479: Ensure that__typing_subst__ returns a tuple#138482

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@ZeroIntensity
Copy link
Member

@ZeroIntensityZeroIntensity commentedSep 3, 2025
edited by bedevere-appbot
Loading

Raise an exception if__typing_subst__ returns a non-tuple object.

The test case is a little messy because it's based on fuzzer-generated code, so I can come up with my own repro if people aren't happy with using it.

returnNULL;
}
if (unpack) {
if (!PyTuple_Check(arg)) {
Copy link
Member

Choose a reason for hiding this comment

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

Do we care abouttuple subclasses here? If so, do we want to test this? Or usePyTuple_CheckExact?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I think it would be fine to do either. It would technically be a breaking change to disallow tuple subclasses here, but I doubt anyone is actually doing that in practice.

Copy link
Member

Choose a reason for hiding this comment

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

It's an internal undocumented API so I wouldn't feel terrible about disallowing tuple subclasses, but we could go either way.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Let's just usePyTuple_Check for the time being. There's no drawback to keeping subclass support here, so we might as well keep it.

"expected a tuple, not %T",arg);
Py_DECREF(arg);
returnNULL;
}
Copy link
Member

Choose a reason for hiding this comment

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

Can't comment there but are we leakingnewargs on line 543 below?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Looks like it. Do you want me to fix that in this PR?

Copy link
Member

Choose a reason for hiding this comment

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

Sure, might as well.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Done.

@AlexWaygoodAlexWaygood removed their request for reviewSeptember 6, 2025 07:41
if (jarg<0) {
Py_DECREF(item);
Py_XDECREF(tuple_args);
Py_DECREF(newargs);

Choose a reason for hiding this comment

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

It is NULL here.

Copy link
MemberAuthor

@ZeroIntensityZeroIntensitySep 6, 2025
edited
Loading

Choose a reason for hiding this comment

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

Ah,tuple_extend steals the reference on failure. I added a comment here instead. Thanks for clearing this up.

Py_DECREF(item);
Py_XDECREF(tuple_args);
PyErr_Format(PyExc_TypeError,
"expected a tuple, not %T",arg);

Choose a reason for hiding this comment

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

This error message is not helpful. Please add what method of what type has been called (this was method__typing_subst__ of original argumentPyTuple_GET_ITEM(args, iarg)).

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Done, it's nowexpected __typing_subst__ of %T objects to return a tuple, not %T. Is that good?

ZeroIntensityand others added2 commitsSeptember 6, 2025 10:18
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Also fix incorrect DECREF.

evil=EvilTypeVar()
typetype_alias[*_]=0
withself.assertRaises(TypeError):

Choose a reason for hiding this comment

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

Could you please test an error message? No need to test the full match, just some unique pattern to ensure that this is an expected TypeError.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Done.

Copy link
Member

@vstinnervstinner left a comment
edited
Loading

Choose a reason for hiding this comment

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

LGTM. The change does fix the crash.

yihong0618 reacted with thumbs up emoji
@ZeroIntensity
Copy link
MemberAuthor

@serhiy-storchaka Would you like to finish up your review? If not, I'll merge this.

Copy link
Member

@serhiy-storchakaserhiy-storchaka left a comment

Choose a reason for hiding this comment

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

LGTM. 👍

@ZeroIntensityZeroIntensity merged commit1da989b intopython:mainSep 11, 2025
45 checks passed
@ZeroIntensityZeroIntensity deleted the gh-138479-unpack-crash branchSeptember 11, 2025 10:39
@miss-islington-app
Copy link

Thanks@ZeroIntensity for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull requestSep 11, 2025
…onGH-138482)Raise an exception if __typing_subst__ returns a non-tuple object.---------(cherry picked from commit1da989b)Co-authored-by: Peter Bierma <zintensitydev@gmail.com>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
@miss-islington-app
Copy link

Sorry,@ZeroIntensity, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 1da989be74eaa94590ec28e750e5352de1ead227 3.13

@bedevere-app
Copy link

GH-138784 is a backport of this pull request to the3.14 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.14bugs and security fixes labelSep 11, 2025
@bedevere-app
Copy link

GH-138786 is a backport of this pull request to the3.13 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.13bugs and security fixes labelSep 11, 2025
ZeroIntensity added a commit to ZeroIntensity/cpython that referenced this pull requestSep 11, 2025
…onGH-138482)Raise an exception if __typing_subst__ returns a non-tuple object.---------Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>(cherry picked from commit1da989b)
ZeroIntensity added a commit to ZeroIntensity/cpython that referenced this pull requestSep 11, 2025
pythonGH-138482)Raise an exception if __typing_subst__ returns a non-tuple object.---------(cherry picked from commit1da989b)Co-authored-by: Peter Bierma <zintensitydev@gmail.com>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
ZeroIntensity added a commit that referenced this pull requestSep 11, 2025
…138482) (GH-138786)*gh-138479: Ensure that `__typing_subst__` returns a tuple (GH-138482)Raise an exception if __typing_subst__ returns a non-tuple object.(cherry picked from commit1da989b)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
hugovk pushed a commit that referenced this pull requestSep 12, 2025
…138482) (#138784)Co-authored-by: Peter Bierma <zintensitydev@gmail.com>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vstinnervstinnervstinner approved these changes

@warsawwarsawwarsaw left review comments

@JelleZijlstraJelleZijlstraJelleZijlstra left review comments

@sobolevnsobolevnsobolevn left review comments

@picnixzpicnixzpicnixz left review comments

@serhiy-storchakaserhiy-storchakaserhiy-storchaka approved these changes

Assignees

@ZeroIntensityZeroIntensity

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@ZeroIntensity@vstinner@warsaw@JelleZijlstra@serhiy-storchaka@sobolevn@picnixz

[8]ページ先頭

©2009-2025 Movatter.jp