Skip to content

gh-130821: Add type information to wrong type error messages #130835

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open

gh-130821: Add type information to wrong type error messages #130835

wants to merge 11 commits into from
+76 −76

Conversation

donBarbos
Copy link
Contributor

@donBarbos donBarbos commented Mar 4, 2025 •
edited
Loading

I got next output for use case from issue:

Foo.__int__() must return type int (not NoneType)
Foo.__float__() must return type float (not NoneType)
Foo.__bytes__() must return type bytes (not NoneType)
Foo.__complex__() must return type complex (not NoneType)
Foo.__bool__() must return type bool (not NoneType)
Foo.__str__() must return type str (not NoneType)

but we still have a lot of other places where wrong type errors have inconsistent messages. should they be updated too?

@donBarbos donBarbos requested a review from markshannon as a code owner March 4, 2025 14:25
@bedevere-app bedevere-app bot mentioned this pull request Mar 4, 2025
Open
jstasiak
jstasiak reviewed Mar 8, 2025
View reviewed changes
Copy link
Contributor

@jstasiak jstasiak left a comment

Choose a reason for hiding this comment

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

Drive-by comment: does it make sense to have tests for these changes?

@donBarbos
Copy link
Contributor Author

Drive-by comment: does it make sense to have tests for these changes?

it seems that we don't check the text of error messages if we don't want to check the error type itself

skirpichev
skirpichev reviewed Apr 28, 2025
View reviewed changes
@skirpichev skirpichev self-requested a review April 28, 2025 13:19
JelleZijlstra
JelleZijlstra reviewed Apr 28, 2025
View reviewed changes
Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Choose a reason for hiding this comment

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

I think many of the changes in wording are not clear improvements.

Objects/abstract.c
PyErr_Format(PyExc_TypeError, "__length_hint__ must be an integer, not %.100s",
Py_TYPE(result)->tp_name);
PyErr_Format(PyExc_TypeError,
"%T.__length_hint__() must return type int (not %T)",
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't read well, I think the existing error is better. Even better might be "__length_hint__ must return an int, not X".

Objects/abstract.c
@@ -887,8 +889,8 @@ PyObject_Format(PyObject *obj, PyObject *format_spec)

if (result && !PyUnicode_Check(result)) {
PyErr_Format(PyExc_TypeError,
"__format__ must return a str, not %.200s",
Copy link
Member

Choose a reason for hiding this comment

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

I like the existing error better. "return type str" sounds strained.

Objects/abstract.c
@@ -1421,17 +1423,17 @@ _PyNumber_Index(PyObject *item)

if (!PyLong_Check(result)) {
PyErr_Format(PyExc_TypeError,
"__index__ returned non-int (type %.200s)",
Copy link
Member

Choose a reason for hiding this comment

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

I don't see much reason to change this error message either.

Objects/abstract.c
@@ -2435,10 +2436,8 @@ method_output_as_list(PyObject *o, PyObject *meth)
PyThreadState *tstate = _PyThreadState_GET();
if (_PyErr_ExceptionMatches(tstate, PyExc_TypeError)) {
_PyErr_Format(tstate, PyExc_TypeError,
"%.200s.%U() returned a non-iterable (type %.200s)",
Copy link
Member

Choose a reason for hiding this comment

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

Here I strongly prefer the old message. Iterable is not a type, it's a category of types.

Objects/abstract.c
@@ -2839,8 +2837,8 @@ PyObject_GetAIter(PyObject *o) {
PyObject *it = (*f)(o);
if (it != NULL && !PyAIter_Check(it)) {
PyErr_Format(PyExc_TypeError,
"aiter() returned not an async iterator of type '%.100s'",
Copy link
Member

Choose a reason for hiding this comment

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

This existing error is pretty confusing, I'd reword it as __aiter__ must return async iterator (got %T).

Objects/typeobject.c
"mro() returned a non-class ('%.500s')",
Py_TYPE(obj)->tp_name);
PyErr_Format(PyExc_TypeError,
"%s.mro() must return class (not %T)",
Copy link
Member

Choose a reason for hiding this comment

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

This is confusing as mro() returns a tuple of classes, not a single class. I think the existing error is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jstasiak jstasiak jstasiak left review comments

@JelleZijlstra JelleZijlstra JelleZijlstra left review comments

@markshannon markshannon Awaiting requested review from markshannon markshannon is a code owner

@ericsnowcurrently ericsnowcurrently Awaiting requested review from ericsnowcurrently ericsnowcurrently is a code owner

@skirpichev skirpichev Awaiting requested review from skirpichev

Assignees
No one assigned
Labels
awaiting review
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@donBarbos @jstasiak @JelleZijlstra @skirpichev