Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

41–50 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#41
post #32
post #10

I'm personally sick of yet-another-config-formats. Why did designing metaformats become cool? They all have warts because using the same symbolic notation for data and structure leads to encoding issues that have cognitive overhead. So instead of getting used to the pratfalls involved in making mistakes in one format/library set, we can do it in a whole bunch of different ones. And of course if anyone uses the new fo…

> I'm personally sick of yet-another-config-formats. Why did designing metaformats become cool? I can't seem to find a date for it, but I think TOML is pretty old, so probably predates a lot of these YACFs. I think that the problem is that it's such an easy workflow: 1. No existing config format is perfect. Look at this should-be easy thing I want to do that isn't easy! 2. Create a new format that makes the desired s…

> I can't seem to find a date for it, but I think TOML is pretty old, so probably predates a lot of these YACFs.

Not _that_ old. TOML's first release was in 2013.

But as a testament to the config format, it was only about a year old when Rust's cargo adopted it fully.

Re: TOML – Tom's Obvious, Minimal Language

#42

YAML and TOML wouldn't have been necessary if JSON had been slightly more expressive. If JSON had * comments * bareword (not double quoted) object key names it'd be a much more suitable configuration file format for everything, and I don't think we'd see the motivation to make things like TOML and YAML.

JSON5 pretty much addresses all the problems with JSON as a config format. I'd love for it to just replace JSON entirely.

https://json5.org/

Re: TOML – Tom's Obvious, Minimal Language

#43
post #17

Earlier quoted context omitted.

> GUIDs, IP Addresses, and byte arrays. In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000 As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but…

It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…

Surely you shouldn’t be limited to types as interpreted and represented in the low-level config parser library but should have a strongly typed representation i of the config structure that you implement in whatever language you’re using.

C# is a good example. JSON doesn’t have any of these types. It doesn’t even make a distinction between integers and other numbers. Yet it’s common practice to marshal these into the kind of types you mentioned at ingestion.

At the end of the day, if you type it with your keyboard, it’s essentially a string.

I think it’s completely fine that all this functionality is part of neither programming languages core libraries nor configuration file formats - there is no one-size-fits-all here.

There are plenty of configuration frameworks that do what you ask for.

Re: TOML – Tom's Obvious, Minimal Language

#44

I still don't understand why the Python steering committee decided to switch to this format for package configuration instead of the perfectly serviceable and existing setup.cfg. Packaging is already a pain to setup, now you gotta learn three (3) different ways to do it (if only to translate from one to the next) because everyone's split. The choice doesn't even matter very much, just settle on something whatever it…

They did settle on something: TOML, in PEP 517/518. There are a ton of in-progress PEPs building on top of PEP 518 to make pyproject.toml the place to put package metadata in a way that will actually be standardized and usable by multiple different packaging tools. setup.cfg is just a crappy form of ini file, with no standards for what it contains other than "what do common tools do". It's a mess, and it's going to get better, but it takes time because consensus is hard and we're all doing this for free.

Re: TOML – Tom's Obvious, Minimal Language

#45
Strict yaml claims to have fixed most of the problems of yaml and other languages used for configuration. Basically it is yaml with only string as a basic datatype, and other complexities removed. Handling of data types is done on a higher schema layer.

https://hitchdev.com/strictyaml/

It's a smaller project so probably could use some support.

Re: TOML – Tom's Obvious, Minimal Language

#46
post #39

Earlier quoted context omitted.

There's not much to learn. It's basically .ini on steroids.

What confuses me is why there isn't a toml module in the standard library.

I think the general feeling in the community is that the standard library is where packages go to die. Once something is in the standard library, it can't get meaningful features/updates outside of the yearly release cycle. pip and setuptools are already vendoring a TOML implementation, and once you have pip, you can pick from multiple great toml implementations that are all under active development. Maybe once the packages/standards for TOML are finalized and the only thing left to do is fix bugs, maybe then we'll see a TOML implementation in the standard library, but in the modern age where you can fetch dependencies at any time, there's honestly not that much incentive for CPython developers to take on more burden of maintenance and development for the already-massive standard library.

Re: TOML – Tom's Obvious, Minimal Language

#47
post #31

TOML sucks in so many ways. It is about 8x better than YAML, INI, or JSON though. It is good enough that I can ignore its flaws.

JSON should be banned for configuration, if only for the fact it doesn’t support comments.

Or trailing commas in lists/objects. That is 90% of what burns me every time I write JSON by hand.

Re: TOML – Tom's Obvious, Minimal Language

#48

YAML and TOML wouldn't have been necessary if JSON had been slightly more expressive. If JSON had * comments * bareword (not double quoted) object key names it'd be a much more suitable configuration file format for everything, and I don't think we'd see the motivation to make things like TOML and YAML.

JSON5 pretty much addresses all the problems with JSON as a config format. I'd love for it to just replace JSON entirely. https://json5.org/

Generally looks good, but ugh, I dislike allowing single quotes. Allowing single quotes has close to zero ergonomic value but increases the number of ways to write the same fundamental thing.

But that's a minor quibble. If everyone adopted this thing instead of legacy JSON, we'd be better-off.

Re: TOML – Tom's Obvious, Minimal Language

#49

YAML and TOML wouldn't have been necessary if JSON had been slightly more expressive. If JSON had * comments * bareword (not double quoted) object key names it'd be a much more suitable configuration file format for everything, and I don't think we'd see the motivation to make things like TOML and YAML.

JSON5 pretty much addresses all the problems with JSON as a config format. I'd love for it to just replace JSON entirely. https://json5.org/

That looks really nice. I might start using it for configuration.

Re: TOML – Tom's Obvious, Minimal Language

#50
post #39

Earlier quoted context omitted.

There's not much to learn. It's basically .ini on steroids.

What confuses me is why there isn't a toml module in the standard library.

Yeah, that's an issue in flake8. There is no stable standard library for something that is supposed to be core to python moving forward.

https://gitlab.com/pycqa/flake8/-/issues/428#note_251982786

Post reply on HN