Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit f4b33f6

Browse files
committed
dict_popitem(): Repaired last-second 2.1 comment, which misidentified the
true reason for allocating the tuple before checking the dict size.
1 parent eb28ef2 commit f4b33f6

1 file changed

Lines changed: 8 additions & 5 deletions

File tree

Objects/dictobject.c

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1362,11 +1362,14 @@ dict_popitem(dictobject *mp, PyObject *args)
13621362

13631363
if (!PyArg_NoArgs(args))
13641364
return NULL;
1365-
/* Allocate the result tuple first. Believe it or not,
1366-
* this allocation could trigger a garbage collection which
1367-
* could resize the dict, which would invalidate the pointer
1368-
* (ep) into the dict calculated below.
1369-
* So we have to do this first.
1365+
/* Allocate the result tuple before checking the size. Believe it
1366+
* or not, this allocation could trigger a garbage collection which
1367+
* could empty the dict, so if we checked the size first and that
1368+
* happened, the result would be an infinite loop (searching for an
1369+
* entry that no longer exists). Note that the usual popitem()
1370+
* idiom is "while d: k, v = d.popitem()". so needing to throw the
1371+
* tuple away if the dict *is* empty isn't a significant
1372+
* inefficiency -- possible, but unlikely in practice.
13701373
*/
13711374
res = PyTuple_New(2);
13721375
if (res == NULL)

0 commit comments

Comments
 (0)