Repository navigation
del list[index] never reallocates the array #158592
Description
Bug report
This works as expected:
>>> import sys
>>> seq = list(range(1000))
>>> sys.getsizeof(seq)
8056
>>> for _ in range(1000):
... seq.pop()
>>> sys.getsizeof(seq)
56But this does not:
>>> import sys
>>> seq = list(range(1000))
>>> sys.getsizeof(seq)
8056
>>> for _ in range(1000):
... del seq[-1]
>>> sys.getsizeof(seq)
8056Perhaps a regression from #115605 (note that the list_ass_slice() call has been replaced with a separate implementation).
CPython versions tested on:
3.13, 3.14, 3.15, CPython main branch
Operating systems tested on:
Linux
Linked PRs
- gh-158592: Reallocate the list's array when deleting by index #158602
- gh-158592: Skip reallocation when shrinking a small list #158787
- [3.15] gh-158592: Skip reallocation when shrinking a small list (GH-158787) #159001
- [3.14] gh-158592: Skip reallocation when shrinking a small list (GH-158787) #159002
Activity
picnixz commentedon Oct 2, 2026
This is not necessarily a bug though? sure it can consume a bit more memory but AFAIK, this was never guaranteed in the first place.
x42005e1f commentedon Oct 2, 2026
Why not, though? The PR made lists thread-safe; it was not intended to change the behavior of deletion by index (there is also no mention of this in the changelog). All other ways of modifying a list reallocate the array. Prior to 3.13, it was also always successfully reallocated. How else can this inconsistency be described if not as a bug? And why should the inability to free memory by deleting by index be expected behavior?
Another example:
picnixz commentedon Oct 2, 2026
Inconsistencies are usually not bugs as long as the actual behavior is unchanged (excluding implementation details and performance regressions that sometimes are not even fixed because deemed too fragile in general) but if other methods do reallocate the array, we can fix it on 3.14+. 3.13 is now security-only unfortunately. But if this warrants a too large refactor, we may likely keep it in 3.15+ or 3.16.
Are you interested in making a PR so that we can evaluate the change and blast radius?
picnixz commentedon Oct 2, 2026
This is an implementation detail. One could delete and reassign just after so sometimes freeing and reallocating memory may not be the best in this case (I am talking in general terms not for this case specifically).
Implementation details are never guaranteed unless documented and can change without notice (but we try not to and I do not know why this specific issue appeared in the first place: was it an omission in the original PR?)
x42005e1f commentedon Oct 2, 2026
If required, then yes. But I will need some time to prepare (by reading the Developer's Guide) so I can understand what is expected of me.
picnixz commentedon Oct 2, 2026
What we expect from you (rough list):
OOC I would be interested in a benchmark where we del an item and reinsert at the same place or append a new item. For benchmarks use pyperf and a PGO+LTO build.
In general: follow code style of the file or apply PEP-7 for C code and PEP-8 for Python code. Avoid magical C tricks that may not be supported everywhere (C11 only).
Those are usually the rules I give to new contributors.
pythongh-158592: Skip reallocation when shrinking a small list
pythongh-158592: Skip reallocation when shrinking a small list
Merge branch 'main' into pythongh-158592
gh-158592: Reallocate the list's array when deleting by index (gh-158602
gh-158592: Skip reallocation when shrinking a small list (gh-158787)
[3.14] gh-158592: Skip reallocation when shrinking a small list (GH-1…
[3.15] gh-158592: Skip reallocation when shrinking a small list (GH-1…
corona10 commentedon Oct 10, 2026
@x42005e1f Thank you for report and contbirution.