Skip to content

gh-130821: Add type info to error message in Modules/_abc.c - #156120

Closed
JMak-Security wants to merge 1 commit into
python:mainfrom
JMak-Security:gh-130821-abc-error-message
Closed

gh-130821: Add type info to error message in Modules/_abc.c#156120
JMak-Security wants to merge 1 commit into
python:mainfrom
JMak-Security:gh-130821-abc-error-message

Conversation

@JMak-Security

Copy link
Copy Markdown

Supersedes the Modules/_abc.c portion of gh-144737, which has gone stale (no activity since a 2026-05-06 stale-bot ping, still unmerged). This picks up that piece specifically, using the type-information convention established by the merged gh-130835.

Change

When an item yielded by a class namespace's items() isn't iterable during abstract-method computation, the raised TypeError now includes the offending item's type:

items() must yield iterable (key, value) pairs, not int

Why not just reuse gh-144737's diff verbatim

gh-144737's _abc.c hunk passes NULL as the message argument to PySequence_Fast():

PyObject *it = PySequence_Fast(item, NULL);

PySequence_Fast() calls PyErr_SetString() with that message when the failure is a TypeError, and PyErr_SetString(exc, NULL) dereferences a null char * inside PyUnicode_FromString(). This is reachable if self.__dict__ (or ns from a custom metaclass namespace) yields an item that isn't iterable and whose iteration failure is a TypeError — the exact case this PR is fixing.

This PR instead keeps a real fallback message on PySequence_Fast() and only replaces it via PyErr_Format() after checking PyErr_ExceptionMatches(PyExc_TypeError), so no NULL ever reaches PyErr_SetString(), and non-TypeError failures (e.g. a raising __iter__) propagate unmodified instead of being overwritten.

Scope

This intentionally covers only Modules/_abc.c, not the other six files gh-144737 touched (_csv.c, _datetimemodule.c, _io/*.c, _pickle.c). That PR's _pickle.c hunk had an open reviewer question (ValueError vs. TypeError for read()'s return-type check) that never reached a resolution, and gh-130821 itself is still marked by @serhiy-storchaka as needing wider consensus for a repo-wide sweep (see the stalled https://discuss.python.org/t/error-messages-for-methods/83362). Keeping this PR narrow avoids re-opening either of those unresolved questions.

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.
@picnixz

picnixz commented Aug 20, 2026

Copy link
Copy Markdown
Member

A stale PR does not mean we would not reconsider it. Should you reope once again a PR just for cherry picking a specific part, we will restrict your access.

@JMak-Security

Copy link
Copy Markdown
Author

Noted, I won't reopen or split off pieces of an existing/stale PR like that again. Appreciate the heads up.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants