Repository navigation
del list[index] never reallocates the array #158592
Description
Activity
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.
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:
>>> import sys >>> seq = list(range(1000)) >>> sys.getsizeof(seq) 8056 >>> for _ in range(1000): ... del seq[-1:] # by slice >>> sys.getsizeof(seq) 56
Reacted by Cool GuyInconsistencies 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?
And why should the inability to free memory by deleting by index be expected behavior?
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?)
Are you interested in making a PR so that we can evaluate the change and blast radius?
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.
What we expect from you (rough list):
- common sense (most important thing)
- human interaction (please do not use an LLM to reply (you do not now, but just so that you know)). You can use one for translation. In particular, be able to explain all changes by yourself (we have too many AI slops, it's burning our review time so we usually focus on high quality PRs that do not need us to fight with an agent with a human as a proxy). You do not seem to be using LLMs and I am grateful for that.
- regression tests (if applicable)
- do not change unrelated code
- follow PEP-7 but use common sense: make minimal changes
- a NEWS entry as it may be a visible change (though not really important) (use python's blurb or the blurb app).
- never force push once a review has been given on your PR (2nd most important thing)
- avoid the "Update branch" button, even if it is tempting. Only hit it when there is a real CI change that you need to exercise.
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.
Reacted by Ilya Egorov, Abduaziz and Donghee Na- added 8 commits that reference this issue
on Oct 4, 2026
Bug report
This works as expected:
But this does not:
Perhaps 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