If ever there was a bikeshed to bikeshed all other bikesheds it’s people creating hierarchies where none is needed. Toml is fine, it’s perfect, it’s exactly what people would expect and remember. But instead you’d have them need to remember that it’s hiding in std. “but if everything’s in std it’s easy to remember!” Yes but then also it’s not needed. And if everything isn’t in std you leave people having to remember if toml was in std, sys, or was it found in tools? Utils? Or did they put it in parsertools? And for what reason? The user knows they want toml. And it’s not like you need to have multiple separate tomls in different places in the hierarchy.
Leaving users having to guess where in the hierarchy you decided to hide something, that they know they’re looking for doesn’t add value. No, just keep it flat and simple.
> creating hierarchies where none is needed. Toml is fine, it’s perfect, it’s exactly what people would expect and remember. [...] And it’s not like you need to have multiple separate tomls in different places in the hierarchy.
Yes, "toml" would be perfect, but we're getting "tomllib" instead, due to the lack of namespacing that the parent comment is lamenting.
The problem with the current situation is that (1) every project has to keep all the standard library modules in mind and make sure to never name a module "io", "site" or "email", etc. and (2) once a non-conflicting name has been picked (e.g. "toml") it will break if the standard library later introduces a module with the same name.
(I'm not advocating for Java's endless chain of single-child directories though.)
Leaving users having to guess where in the hierarchy you decided to hide something, that they know they’re looking for doesn’t add value. No, just keep it flat and simple.