TOML is great if you think of it as JSON, but optimized for being written by humans instead of machines. I hope no new first-class types or syntax features ever get added after the 1.0 release so it can have the same stability that makes JSON great. The vast majority of the proposals that I see in the repo's issues would collectively destroy the value of TOML, and I'm glad the current maintainer seems to have the sense and fortitude to resist such additions.
TOML – Tom's Obvious, Minimal Language
71–80 of 163 posts
Re: TOML – Tom's Obvious, Minimal Language
#72Earlier 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…
You're assuming that all languages have a "System.Guid" type that the configuration value can be parsed into.
If you want a strongly type configuration that works across many languages, you'll need to also provide the per-language implementation of those types to fill the gaps.
You'll notice that JSON, YAML, INI, and XML also do not have IP address nor GUID types.
What configuration format does meet your approval?
Re: TOML – Tom's Obvious, Minimal Language
#73Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss. I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating. YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration. JSON is too strict/simple.…
There are a few projects with a similar feel as json yet allowing nice to haves like comments and trailing commas:
* json5
* HCl
* hjson (now unmaintained)
Re: TOML – Tom's Obvious, Minimal Language
#74Earlier 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…
Don't like stringly-typed programming or configuration? There's Dhall for you https://dhall-lang.org/
> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports
It's specifically not Turing-complete so it has a number of safeties built in because of this. I've been using it more and more wherever possible as of late.
Re: TOML – Tom's Obvious, Minimal Language
#75TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
I've been using TOML recently and what displeases me most is that almost all string values need to be quoted.
string quotation is a very interesting topic, one variation I would like in a config file is a single backtick that continues up to the first line break
Re: TOML – Tom's Obvious, Minimal Language
#76Earlier quoted context omitted.
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 p…
> the standard library is where packages go to die I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.
my understanding is that the batteries included philosophy wasn't really successful. probably it would have been better if they had a smaller standard library providing core language-level functionality and then many blessed p packages that with independent versioning
Re: TOML – Tom's Obvious, Minimal Language
#77YAML 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.
Yep. And trailing commas,
or also no commas at all
Re: TOML – Tom's Obvious, Minimal Language
#78Earlier quoted context omitted.
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 p…
> the standard library is where packages go to die I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.
Python now includes pip itself in the standard library (which is a spectacularly poor decision IMO).
Re: TOML – Tom's Obvious, Minimal Language
#79Earlier quoted context omitted.
But surely strings are valid? Unless you want some kind of static type checking/linting for eg an ipv4 vs ipv6 key? Strings are very portable as well (POD). Plenty of real world applications use static hostnames and rely on DCHP to assign IPs. When you have systems that can fail hard and you need to replace a NIC, it saves having to update either a ton of config files, router configs, or your hosts file(s). Most netw…
IP is a configuration option for most server software, it’s just that it usually needs to be set to 0.0.0.0 and that is the default anyway so most admins just leave it out.
Lets use :: nowadays ;-)
After all we got ~16 % IPv6 traffic hitting our repository CDN. (seems to match with an observation of LWN https://lwn.net/Articles/808896/ )
Re: TOML – Tom's Obvious, Minimal Language
#80Earlier quoted context omitted.
> the standard library is where packages go to die I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.
my understanding is that the batteries included philosophy wasn't really successful. probably it would have been better if they had a smaller standard library providing core language-level functionality and then many blessed p packages that with independent versioning
It was successful at the time. Remember Python is nearly 30 years old now, and has always had the worst dependency management of any major language.