gh-130821: Make error messages consistent in Modules/ - #144737
gh-130821: Make error messages consistent in Modules/#144737Cityfishman wants to merge 1 commit into
Conversation
Update error messages in Modules/ directory to use consistent format with %T formatter for type names, similar to changes made in PR python#130835 for Objects/ directory. Changes: - Modules/_abc.c: items() error message - Modules/_datetimemodule.c: divmod() error message - Modules/_pickle.c: read() error message - Modules/_io/bufferedio.c: read() and readall() error messages - Modules/_io/iobase.c: read() error message - Modules/_io/textio.c: decoder and encoder error messages - Modules/_csv.c: iterator error message
|
All commit authors signed the Contributor License Agreement. |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
| @@ -1302,8 +1302,8 @@ _Unpickler_ReadIntoFromFile(PickleState *state, UnpicklerObject *self, char *buf | |||
| } | |||
| if (!PyBytes_Check(data)) { | |||
| PyErr_Format(PyExc_ValueError, | |||
There was a problem hiding this comment.
It seems strange that this raises a ValueError and not a TypeError since the error is that the return value of read() is not a bytes object, but instead a different type. Not sure the potential impact of changing this from a ValueError to a TypeError, but a TypeError feels like the better option as it makes it consistent with all the other changes in this PR and also in #130835.
|
This PR is stale because it has been open for 30 days with no activity. |
When an item yielded by a class namespace's items() is not iterable during abstract-method computation, include the type of the offending item in the raised TypeError, matching the type-information convention established in pythongh-130835. This targets the same _abc.c hunk that pythongh-144737 (now stale) proposed, using PyErr_ExceptionMatches to only replace the message on a genuine TypeError instead of passing NULL through PySequence_Fast, which risks a NULL PyErr_SetString call if that path is ever reached with a different underlying error.
|
Since this PR has been stale since 2026-05-06 and I can't push to its branch, I've opened #156120 to pick up the |
|
This is not a reason to open PRs and you should stop this as this will be considered a spam. Stale PRs can be revived |
|
More precisely: I am not even sure we want this. So this either needs discussion revival or broader consensus |
Update error messages in Modules/ directory to use consistent format with %T formatter for type names, similar to changes made in PR #130835 for Objects/ directory.
Changes: