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.

>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.

If you don't care about the format, why would you be using TOML in the first place? Just use JSON.

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.

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).

>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.

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.

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.

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.

> 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”.

> If the correct design isn't obvious, better to leave it out for now

In the face of ambiguity, refuse the temptation to guess

I assume reading toml files constitutes 90% of the use cases, as it's mostly used for configuration, much like the configparser module.

>as it's mostly used for configuration

Well, people write configuration in JSON, XML, and INI and process those and re-serialize to those formats too

It's also handy for making one-off scripts for changes to a big-ish configuration file - even if it's not a part of some automated pipeline.

There was a long debate about this, and the conclusion was:

There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do you do with comments, do you allow partial updates...). Therefor reading is easy to get right, but writing less so, and once it's in the stdlib, we can't make quick changes to the API.

Since reading is already very useful, and tomli author's is ready to provide that for free, let's include it now and see writing later.

>There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do you do with comments, do you allow partial updates..

Then don't use TOML for internal stuff?

Or just settle on a way your lib writes it, and if every parser out there can read it anyway, and get the same deserialized structure, it doesn't matter which way you write it exactly...

I'm just giving you a summary of the rational.

As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments.

You will find the detailed rational in the PEP, and link to the various discussions.

>As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments.

Well, the same debates happened over many other decisions debated, acted upon, and later regretted and reverted. At some point the GIL seemed like a good decision too!

Obviously the complexity level is different, but to me you sound like someone complaining about Linux adding support for a new filesystem, but read-only at first. Why all the hostility?

It's a complain about a release decision. Where's the hostillity?

No need to project psychology on it...

That's an argument for not adding a TOML writer right now. The correct design isn't obvious so there'd be a risk of a bad design getting locked in.

The GIL is a good decision and has been a sound engineering tradeoff for decades. It's only been the past few years that running the interpreter without a GIL has been even remotely feasible (cf the gilectomy project). The GIL is a relatively straightforward way to hold back a tremendous amount of complexity.

Similarly, TOML writing is a ton of completely. The org isn't opposed to adding toml writing to the stdlib fundamentally, they just aren't rushing and want to hammer out all of the grossness first.

I have plenty of cases with yaml where I care about the formatting of the serialized output. I have to use obscure hooks into pyyaml's inner workings to tweak things just right. In some cases, I end up having to do some of the serialization myself. While technically it doesn't matter because it's all equivalent once in memory, there are externalized costs once you're integrated into a large system. The whole point of using something like yaml or toml is to be human friendly.