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.