TOML: Tom's Obvious Minimal Language

Post by afiori » Sun, May 21, 2023, 11:32 AM UTC

lexicality wrote: post #6

the_mitsuhiko wrote: post #3

The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.

The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.

Post by arp242 » Sun, May 21, 2023, 11:33 AM UTC

the_mitsuhiko wrote: post #7

lexicality wrote: post #6

Earlier quoted context omitted.

The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.

> The Billion Dollar Mistake lives on. I disagree. There is a big difference between configuration language formats and programming languages. > To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound. I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.

Post by arp242 » Sun, May 21, 2023, 11:36 AM UTC

SPBS wrote: post #10

JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516

  tbl = {
     hello = "world",
  }

Post by the_mitsuhiko » Sun, May 21, 2023, 11:38 AM UTC

arp242 wrote: post #14

the_mitsuhiko wrote: post #7

Earlier quoted context omitted.

> The Billion Dollar Mistake lives on. I disagree. There is a big difference between configuration language formats and programming languages. > To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound. I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.

> There is a big difference between configuration language formats and programming languages. In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.

Post by lexicality » Sun, May 21, 2023, 11:47 AM UTC

the_mitsuhiko wrote: post #17

lexicality wrote: post #13

Earlier quoted context omitted.

> There is a big difference between configuration language formats and programming languages. You're right! But in my opinion the difference is that a configuration file should have a default state that could be written to disk and loaded with no change in behaviour. eg you can set `feature = "on"` or `feature = "off"` and if you don't set either it's the same as writing `feature = "off"`. Having a secret third thing…

There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values. It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.

    In [1]: example = {"foo": None}

    In [2]: print(example["foo"])
    None

    In [3]: print(example["bar"])
    ---------------------------------------------------------------------------
    KeyError                                  Traceback (most recent call last)
    Cell In[3], line 1
    ----> 1 print(example["bar"])

    KeyError: 'bar'

    In [4]: print(example.get("bar", "sensible default"))
    sensible default