gh-138479: Ensure that __typing_subst__ returns a tuple#138482
gh-138479: Ensure that __typing_subst__ returns a tuple#138482ZeroIntensity merged 11 commits intopython:mainfrom
__typing_subst__ returns a tuple#138482Conversation
| return NULL; | ||
| } | ||
| if (unpack) { | ||
| if (!PyTuple_Check(arg)) { |
There was a problem hiding this comment.
Do we care about tuple subclasses here? If so, do we want to test this? Or use PyTuple_CheckExact?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
It's an internal undocumented API so I wouldn't feel terrible about disallowing tuple subclasses, but we could go either way.
There was a problem hiding this comment.
Let's just use PyTuple_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); | ||
| return NULL; | ||
| } |
There was a problem hiding this comment.
Can't comment there but are we leaking newargs on line 543 below?
There was a problem hiding this comment.
Looks like it. Do you want me to fix that in this PR?
Objects/genericaliasobject.c
Outdated
| if (jarg < 0) { | ||
| Py_DECREF(item); | ||
| Py_XDECREF(tuple_args); | ||
| Py_DECREF(newargs); |
There was a problem hiding this comment.
Ah, tuple_extend steals the reference on failure. I added a comment here instead. Thanks for clearing this up.
Objects/genericaliasobject.c
Outdated
| Py_DECREF(item); | ||
| Py_XDECREF(tuple_args); | ||
| PyErr_Format(PyExc_TypeError, | ||
| "expected a tuple, not %T", arg); |
There was a problem hiding this comment.
This error message is not helpful. Please add what method of what type has been called (this was method __typing_subst__ of original argument PyTuple_GET_ITEM(args, iarg)).
There was a problem hiding this comment.
Done, it's now expected __typing_subst__ of %T objects to return a tuple, not %T. Is that good?
Co-authored-by: Serhiy Storchaka <[email protected]>
Also fix incorrect DECREF.
Lib/test/test_typing.py
Outdated
|
|
||
| evil = EvilTypeVar() | ||
| type type_alias[*_] = 0 | ||
| with self.assertRaises(TypeError): |
There was a problem hiding this comment.
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.
|
@serhiy-storchaka Would you like to finish up your review? If not, I'll merge this. |
|
Thanks @ZeroIntensity for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
…onGH-138482) Raise an exception if __typing_subst__ returns a non-tuple object. --------- (cherry picked from commit 1da989b) Co-authored-by: Peter Bierma <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
|
Sorry, @ZeroIntensity, I could not cleanly backport this to |
|
GH-138784 is a backport of this pull request to the 3.14 branch. |
|
GH-138786 is a backport of this pull request to the 3.13 branch. |
…onGH-138482) Raise an exception if __typing_subst__ returns a non-tuple object. --------- Co-authored-by: Serhiy Storchaka <[email protected]> (cherry picked from commit 1da989b)
pythonGH-138482) Raise an exception if __typing_subst__ returns a non-tuple object. --------- (cherry picked from commit 1da989b) Co-authored-by: Peter Bierma <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…138482) (#138784) Co-authored-by: Peter Bierma <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
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.