4 ms·

Parsing TOML is clearly useful, but the case for serialization is much less clear. It's meant to be human-writable, and offers multiple ways to express the sam

Parsing TOML is clearly useful, but the case for serialization is much less clear. 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.

coldtea 4y ago
>Parsing TOML is clearly useful, but the case for serialization is much less clear. 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.
- dragonwriter 4y ago
  > The obvious use case is reading, altering AND writing back 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”.
- iainmerrick 4y ago
  If you don't care about the format, why would you be using TOML in the first place? Just use JSON.
  - coldtea 4y ago
    Who said I don't care about the format in general? I don't care about specific stylistic options in serializing to the format that are all parsed the same way anyway.
    - iainmerrick 4y ago
      That was how I interpreted this (but I didn’t say “in general”): 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).
      - coldtea 4y ago
        >presumably you want to be able to format things nicely by hand because that’s the whole point of TOML. 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.
- tarranoth 4y ago
  What about yaml? Most people use it for configuration, but few would write out a yaml file as output instead of a json file even though they could.
- gtirloni 4y ago
  If you spend a few minutes thinking about practical implications of a piece of code parsing toml and writing it back with stylistic changes, I'm sure you'll find many such situations.
  - coldtea 4y ago
    I covered that though: this would be the case for ANY existing TOML serializing library. People already use those, and are OK with them picking a specific output style. So, they could use the functionality in the stdlib too.
hbrn 4y ago
> If the correct design isn't obvious, better to leave it out for now In the face of ambiguity, refuse the temptation to guess

coldtea 4y ago

>Parsing TOML is clearly useful, but the case for serialization is much less clear. 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.

dragonwriter 4y ago
> The obvious use case is reading, altering AND writing back 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”.
iainmerrick 4y ago
If you don't care about the format, why would you be using TOML in the first place? Just use JSON.
- coldtea 4y ago
  Who said I don't care about the format in general? I don't care about specific stylistic options in serializing to the format that are all parsed the same way anyway.
  - iainmerrick 4y ago
    That was how I interpreted this (but I didn’t say “in general”): 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).
    - coldtea 4y ago
      >presumably you want to be able to format things nicely by hand because that’s the whole point of TOML. 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.
tarranoth 4y ago
What about yaml? Most people use it for configuration, but few would write out a yaml file as output instead of a json file even though they could.
gtirloni 4y ago
If you spend a few minutes thinking about practical implications of a piece of code parsing toml and writing it back with stylistic changes, I'm sure you'll find many such situations.
- coldtea 4y ago
  I covered that though: this would be the case for ANY existing TOML serializing library. People already use those, and are OK with them picking a specific output style. So, they could use the functionality in the stdlib too.

hbrn 4y ago

> If the correct design isn't obvious, better to leave it out for now In the face of ambiguity, refuse the temptation to guess