I never met any format where parsing it is useful but serializing to it is not. Maybe some binary format where I only care for e.g. playing a video or decoding an image. For a configuration format though?
The obvious use case is reading, altering AND writing back.
>It's meant to be human-writable, and offers multiple ways to express the same table data; what format should a TOML serializer use?
It should just pick one and stick with it?
If N versions of the format express the same data (deserialize into the same structure) then it doesn't really matter from a functional way which they pick.
Users would still need to pick a TOML lib to write data - so they already OK with that lib picking a specific way. Why wouldn't they be OK with Python do it?
If they don't want nobody to mess with their hand-written TOML files, they can always just not write them back from Python.
I don't care about specific stylistic options in serializing to the format that are all parsed the same way anyway.
If N versions of the format express the same data (deserialize into the same structure) then it doesn't really matter from a functional way which they pick.
To clarify my point, if you’re using TOML, presumably you want to be able to format things nicely by hand because that’s the whole point of TOML. If you don’t need to do that, just use JSON. So I don’t see a whole lot of value in a tool for serialising data into boilerplate TOML (or YAML, etc).
For me the whole point of TOML is as a stricter, saner, YAML-type (human readable that is) config first, and a format used in several places, including upcoming Python standards, second.
Couldn't care less about formatting things nicely by hand.
That’s actually (if what you are reading is human-edited input thar you might transform but expect to be human edited) a hard case, because then you want to keep as much as possible the format entered in, while accommodating changes, which is easy to subjectively evaluate but seems potebtially hard to express mechanically in a way which would provide generally optimal UX. You don’t want to hand edit config and have a UI, but have an “I touched it with the UI and made a couple small changes out of dozens of entries and now its unrecognizable”.
It's meant to be human-writable, and offers multiple ways to express the same table data; what format should a TOML serializer use?
I can see that you might want to programmatically edit a TOML file, preserving the rest of its layout unchanged. That's a bit fiddly to get right, and needs a different interface from a pure serializer. If the correct design isn't obvious, better to leave it out for now. It could still be added later.