Repository navigation
update() on an out-of-order table raises IndexError after a sub-table fragment was popped #675
Description
Versions tested: tomlkit 0.15.2 from PyPI (the newest release on 2026-10-21) and the master branch at
eddd27e43a62fe58707c311bfad2f52e72493f53 (its head on 2026-10-21); Python 3.11.10 on Linux.
Reproduce (one command):
python3 -c '
import tomlkit
doc = tomlkit.parse("[y.y.b]\nc = 1\n[y]\nd = 1\n[y.b]\ne = 2\n[y.y]\n")
doc["y"]["y"].pop("b")
doc["y"].update({"y": [{"z": 1}], "b": {"e": -0.5}})
print(tomlkit.dumps(doc))
'
The document is valid TOML: tomllib.loads reads it as {'y': {'y': {'b': {'c': 1}}, 'd': 1, 'b': {'e': 2}}}.
Expected: the update succeeds and the document can be dumped.
Observed (the same on both versions):
File ".../tomlkit/container.py", line 1262, in __setitem__
old_value = self._tables[map_indices[0]][key]
~~~~~~~~~~~~^^^^^^^^^^^^^^^^
IndexError: list index out of range
Setting the two keys one at a time (doc["y"]["y"] = [{"z": 1}], then doc["y"]["b"] = {"e": -0.5}) after the same pop does not
raise. We have not looked for the cause.
Found while testing tomlkit's editing API against the standard library's tomllib with generated documents.
Possibly related: #196 (out-of-order sections), though that report is about _insert_after, not update().
Activity
rajmodi8905 commentedon Oct 22, 2026
Hi! I've reproduced this on eddd27e and prepared a local fix. Replacing a key split across table fragments currently removes entire later fragments, including unrelated sibling keys. The change removes only the replaced key, and drops a fragment only when it is empty. This preserves both
dandbin the example.I added 12 regression cases covering table, array-of-tables and scalar replacements, both update orders, and with/without the
pop. All 1,215 tests pass, along with Ruff lint and formatting checks. Mypy reports the same six errors on unchanged master and the patch.Would you be happy for me to take this issue and submit the fix?
Upua commentedon Oct 22, 2026
Yes, please take it, and thank you for reproducing it.
One observation from the same document that may belong in your regression cases, since your description ("removes entire later fragments, including unrelated sibling keys") sounds like the same mechanism: with or without the
pop, aftertomlkit.dumps(doc)anddoc.unwrap()no longer containd = 1from the[y]table (tested on 0.15.2 andmasterat eddd27e). I had not filed it separately because I could not tell whether it was the same defect; if your fix keepsdthere too, that would settle it.fix: preserve siblings when updating out-of-order tables
rajmodi8905 commentedon Oct 27, 2026
Hi maintainers, the proposed fix is in #677, where the reporter has verified the reproducer and sibling-key preservation. I'd appreciate a review when you have time. Thank you!