I agree here. I briefly urged against using the less used TOML format, but I have no real skin in the game around packaging. I like YAML, but that's also not in the standard library, even if more widely used.
But given that packaging is committed to TOML, I think that's a strong case for including a library in stdlib. The PEP 517/518 authors had their reasons that were accepted. Now there is broad ecosystem that is built on that choice. Let's support it.
>> He's referring to PEPs 518 and 517 [1], which indeed standardize on
>> TOML as a file format for Python package build metadata.
>>
>> I think moving anything into the stdlib would be premature though –
>> TOML libraries are under active development, and the general trend in
>> the packaging space has been to move things *out* of the stdlib (e.g.
>> there's repeated rumblings about moving distutils out), because the
>> stdlib release cycle doesn't work well for packaging infrastructure.
>
> If I had the energy to argue it I would also argue against using TOML
> in those PEPs. I personally don't especially care for TOML and what's
> "obvious" to Tom is not at all obvious to me. I'd rather just stick
> with YAML or perhaps something even simpler than either one.
This thread isn't about regretting past decisions but what makes sense given current realities though.
/ Anders