Repository navigation
Conversation
Seems like this would be worth a note in the readme or something. It is a break from the promise currently made:
Though, tomlkit would not be the only one - cf https://github.com/toml-rs/toml/tree/main/crates/toml_edit#limitations |
|
Good point — added a Limitations note to the README spelling this out. As you say, it's the same trade-off |
…ent after an unrelated table
When a sub-table header such as [fruit.apple.texture] follows the array
[[fruit]] with an unrelated table in between, the parser rebuilds it as a
fresh super table named "fruit" and tries to append it to the document,
colliding with the existing array of tables and raising
ParseError: Key "fruit" already exists.
even though the document is valid TOML 1.0.0. The contiguous form (no
intervening table) already worked because the sub-table is consumed while
the array element is still being parsed.
A sub-table header that refers to an existing array of tables extends the
array's last element, regardless of any tables defined in between, so merge
its contents into that element instead of treating it as a redefinition.
Defining a non-super table with the same name as an array (e.g. [fruit]
after [[fruit]]) is still a genuine conflict and continues to raise.
Fixes python-poetry#261
7a32d21 to
425859d
Compare
Fixes #261.
tomlkitraisesParseError: Key "fruit" already exists.on valid TOML when a sub-table header extends an array of tables with an unrelated table in between:The contiguous form (without
[potato]) already parses, because[fruit.apple.texture]gets consumed while the array element is still being parsed. Once an unrelated table breaks that up, the header is rebuilt as a fresh super table namedfruitand appended to the document, colliding with the existing array.A sub-table header naming an existing array of tables refers to the array's last element, so I merge its contents there instead of treating it as a redefinition. Defining a real table with an array's name (
[fruit]after[[fruit]]) is still a genuine conflict and keeps raising.One caveat worth flagging: on the round trip the out-of-order sub-table is normalized into the array element rather than kept at its original position. Byte-for-byte preservation isn't reachable here the way it is for plain tables — those lean on
OutOfOrderTableProxy, which is dict-shaped, whereas an array element has to round-trip back as a list. The data is correct and stable on re-dump; happy to dig into preserving the exact layout if you'd prefer.Added a regression test; full suite, ruff and mypy all pass.