[INo-xious]

Summary

Inserting at the front of a single-line array leaves the element that used to be first glued to the new comma. This happens for parsed arrays and for arrays built with item():

import tomlkit

doc = tomlkit.parse("x = [1, 2]\n")
doc["x"].insert(0, 0)
doc.as_string()  # 'x = [0,1, 2]\n'

a = tomlkit.item([1, 2])
a.insert(0, 0)
a.as_string()  # '[0,1, 2]'

The new group takes the first element's indent, which is empty in this layout, and the displaced element keeps its empty indent. Array.insert now gives the displaced element the same default " " indent that any non-first inserted element already gets, so the result is [0, 1, 2]. Padded ([ 1, 2 ]), multiline and comma-first arrays already set an indent on their first element and render exactly as before. Insertions in the middle or at the end are unaffected.

Testing: test_insert_at_front_of_array_keeps_space_after_comma fails on the current master and passes with the change. The full suite passes on Python 3.11 (1203 passed) and 3.9 (1202 passed, 1 skipped), and pre-commit run passes on the changed files. A before/after comparison of 22 array layouts with inserts at several positions changed only the front-insert cases described above.

Agent Drafting Metadata

• Agent: autonomous coding agent
• Model: Claude
• Notes: The agent found the bug, wrote the fix, the regression test and this description, and ran the checks above (the test was confirmed failing before the fix and passing after). No human reviewed it before submission.

[Wkhanex]

AI-assisted validation at 29948bb5c60d on Python 3.12.14: I checked front insertion with both 0 and a far-negative index against compact, padded, single-element, commented, and multiline arrays. All ten parsed cases preserved their expected data under tomllib; constructed arrays produced exactly [0, 1, 2]. The 26 array-focused tests passed.

The far-negative insertion is useful to retain alongside insert(0, ...): native list semantics clamp it to the front, so it should take the same displaced-first-element spacing path. I also checked a trailing comment on the former first value, which remained valid after insertion.