Start a new line before the closing bracket of a commented array

[dchaudhari7177]

Fixes #580.

Problem

>>> array = tomlkit.array()
>>> array.add_line("foo", comment="bar")
>>> print(array.as_string())
[
    "foo", # bar]

The closing bracket sits inside the comment, so the output is no longer valid TOML and tomlkit.loads() on the containing document raises UnexpectedCharError.

Cause

For a non-multiline array as_string() is:

return f"[{''.join(v.as_string() for v in self._iter_items())}]"

add_line(comment=...) appends a Comment as the last item and nothing after it. A comment runs to the end of its line, so anything concatenated after it is commented out — including the bracket.

Fix

When the last rendered item is a Comment, emit a newline and the array's indent before the bracket, mirroring what the multiline branch already does.

The issue suggests instead having add_line flip the array to multiline. I went the other way because the multiline branch re-renders with a fixed four-space indent and its own comma placement, which would throw away the layout add_line exists to control precisely (add_line(1, 2, 3) would become one element per line). This change only adds the separator that is actually missing.

Scope

Only affects arrays whose rendered items end with a comment. A parsed document can't reach that state — the parser has to consume the ], and a comment always ends at a newline, so a parsed array's last item is whitespace. So this is confined to arrays built through the API, and the existing test_array_add_line (which ends with add_line(indent="")) is unchanged, as is byte-for-byte round-tripping of parsed documents.

Tests

• test_array_add_line_trailing_comment_does_not_hide_bracket — the reported case, plus a re-parse of the containing document.
• test_array_add_line_trailing_comment_closing_line_is_not_doubled — calling add_line(indent="") after a comment still produces exactly one closing line, not two.

Full suite passes (1053 tests).

🤖 Generated with Claude Code

[dimbleby]

why is this better or worse than the existing pull request #581?

@dchaudhari7177 you should likely have your bot check for already-open pull requests before creating new ones

[dchaudhari7177]

You're right — #581 covers the same issue (#580) and was opened first, so closing this in its favour. Apologies for the duplicate; I should have checked the open queue before starting. Doing that from now on.