[chrismorgan]

But why tomllib rather than toml? That’s just weird. I thought they’d long stopped using the -lib suffix as pointless.

(Judging by https://docs.python.org/3/library/, there are 17 of them already, disregarding zlib, mostly niche and of ancient lineage. Comparing with https://docs.python.org/2/library/, it looks like three have been added in the py3k era. reprlib in 3.0 (with unpythonic naming conventions, dunno what’s up with that), pathlib in 3.4, and graphlib in 3.9 (though the version it was added in is missing from the page; I invite someone else to fix this or file a bug report)—so I guess -lib suffixes aren’t quite as dead as I’d thought.)

[azov]

This is what you get when you missed a chance to namespace standard library many years ago. Should have been std.toml.

[isitmadeofglass]

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.

[ptx]

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

[toyg]

They reorg'd in 3.0 but fell short of mandating namespace guidelines, so it was inevitable that the chaos would come back in at some point.

Who knows, it could be a good feature to earn the 4.0 moniker.

[ruuda]

To avoid breaking exiting code that imports "toml", which is more common than "tomllib".

[underyx]

https://peps.python.org/pep-0680/#alternative-names-for-the-...

[pid-1]

toml was already taken and no one could contact the author.