[feiiiiii5]

Summary

Container.__copy__ copies the dict mirror, _body, _map and _out_of_order_keys, but not _table_keys — while __setstate__ does restore that field when pickling, and _raw_append maintains it for every keyed table. With the bookkeeping missing, the merge heuristic in _handle_merge reads self._table_keys[-1] and crashes on an empty list, so a copied container cannot append a table whose name already exists, while the same append on the original works:

doc = tomlkit.parse("[a.b.c]\nx = 1\n")
a_copy = doc["a"].copy()
a_copy.append("b", tomlkit.table(True))
# IndexError: list index out of range   (doc["a"].append(...) is fine)

The public doc.copy() path hits the same crash via doc_copy.append("a", super_table). Fix is one line in __copy__ (c._table_keys += self._table_keys extends the new container's fresh list, so the original is unaffected).

New test test_toml_document_copy_keeps_table_keys appends a super table to a copy and asserts the merged rendering round-trips with both tables intact; it raises IndexError on current master. Full suite: pytest tests/ --ignore=tests/test_toml_tests.py — 524 passed (523 baseline + the new test).

Agent Drafting Metadata

• Agent: ZCode coding agent
• Model: GLM-5.3
• Notes: Reproduction, one-line fix and regression test verified in an isolated worktree against origin/master (eddd27e); full offline test suite run before and after.

[dimbleby]

Explain why not #672

[feiiiiii5]

Good catch — I missed #672: my duplicate search keyed on the IndexError symptom wording and didn't surface its title. It was opened 8 days earlier and the source fix is identical (carry _table_keys through __copy__), with better tests than mine, so #672 deserves the merge. I'll close this one as a duplicate; nothing in it is worth salvaging over there.

[feiiiiii5]

I missed #672 — my duplicate search keyed on the IndexError symptom and didn't surface its title. It was opened 8 days earlier and the source fix is identical (carry _table_keys through __copy__), with better tests than mine. Closing in favour of #672. Thanks for the pointer.