Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

Post reply on HN
Print view View original

161–170 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#161

Post by rayrrr »

Simran-B wrote: post #144
friend_and_foe wrote: post #103

I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but…

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

YAML is not reliably machine-readable, nor was it designed to be. TOML was designed to be machine-readable, but otherwise fulfilling a similar use case as YAML.

Re: TOML: Tom's Obvious Minimal Language

#163

Post by magicalhippo »

dijit wrote: post #143
Waterluvian wrote: post #137

Earlier quoted context omitted.

JSON’s numbers are not IEEE-754. They’re numbers with an optionally infinite number of decimal places. It’s up to a parser to handle it. Python can parse these into integers if there isn’t a decimal place. It’s in the name, but be careful not to get confused with JSON being JavaScript.

You wrote this as if it’s a defense but honestly I feel even more terrified of JSON numbers now than I was before entering this thread, and before reading your comment. Not following a set standard is undefined behaviour, leaving it up to the implementation is a large problem in other areas of computer science. Such as C compilers.

If you want something stricter, specify it in the JSON Schema and use that[1].

You could declare your own "int32" type[2] for example, and use that. Then validate the input JSON against the schema before parsing it further.

[1]: https://datatracker.ietf.org/doc/html/draft-bhutton-json-sch...

[2]: https://json-schema.org/draft/2020-12/json-schema-core.html#...

Re: TOML: Tom's Obvious Minimal Language

#164

Post by crabbone »

It's another junk format in the sea of junk formats.

It sucks for describing data, its structure is too primitive, has wrong primitives, doesn't allow extension and has no mitigations for that.

Essentially, it's used because it's simple to parse and there are existing parsers. But the problems it creates are very complicated.

So, here's one example of a popular use-case: pyproject.toml. I mean, PyPA aren't the brightest minds around, so, they've created this joke. The stated goal of pyproject.toml was unification of dependency / requirements specification. But, what they ended up doing is this:

    [tool.joke]
    tool.joke.requires=

    [tool.clown_fiesta]
    tool.clown_fiesta.requires=
The problem here is that the goal was to unify, to specify requirements only once... but in practice, you still have to write them twice, and, of course, it's possible that "joke" and "clown_fiesta" don't use the same format to specify requirements. So, you have no way to specify requirements for both at once, and no way to process similar structures, to present them differently to different tools.

And so, PyPA has created an piece of junk software that today has to be used by hundreds of thousands. Because we live in the world of worse is better.

Re: TOML: Tom's Obvious Minimal Language

#165

Post by Gare »

MrJohz wrote: post #154
Simran-B wrote: post #144

Earlier quoted context omitted.

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environmen…

> YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load.

This was fixed in YAML 1.2, but the problem is that almost nobody uses (and there is patchy support for) it.

Re: TOML: Tom's Obvious Minimal Language

#166

Post by jborean93 »

crabbone wrote: post #164

It's another junk format in the sea of junk formats. It sucks for describing data, its structure is too primitive, has wrong primitives, doesn't allow extension and has no mitigations for that. Essentially, it's used because it's simple to parse and there are existing parsers. But the problems it creates are very complicated. So, here's one example of a popular use-case: pyproject.toml. I mean, PyPA aren't the bright…

Can you share an actual example where you need to specify requirements twice. With pyproject.toml I know of 3 ways requirements are specified and they are all used by different things:

1. Build requirements - requirements needed to build your package from an sdist

2. Runtime requirements - requirements your library needs at runtime

3. Extra requirements - optional runtime requirements

For example my library pyspnego https://github.com/jborean93/pyspnego/blob/main/pyproject.to... has all 3:

1. Cython for Win32 needed to build the sdist and setuptools as the general build system - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

2. cryptography as a runtime dependency - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

3. optional extras kerberos and yaml - https://github.com/jborean93/pyspnego/blob/c3db058b636fc102f...

Granted the toml format and what is used in pyproject.toml has its warts but I'm curious what your joke and clown_fiesta examples are actually from as from where I am standing each section currently serve different purposes.

Re: TOML: Tom's Obvious Minimal Language

#167

Post by Spivak »

crabbone wrote: post #164

It's another junk format in the sea of junk formats. It sucks for describing data, its structure is too primitive, has wrong primitives, doesn't allow extension and has no mitigations for that. Essentially, it's used because it's simple to parse and there are existing parsers. But the problems it creates are very complicated. So, here's one example of a popular use-case: pyproject.toml. I mean, PyPA aren't the bright…

Huh?

    [project]
    dependencies = [blah]

    [project.optional-dependencies]
     groupname = [blah]
Install project with `pip install .` and install optional deps with `pip install .[groupname]`.

Re: TOML: Tom's Obvious Minimal Language

#168

Post by crdrost »

Waterluvian wrote: post #152
crdrost wrote: post #149

Earlier quoted context omitted.

Yes but this is a necessary limitation for all human readable numbers. The context decides what to deserialize into and different contexts/languages will choose bigint vs i64 vs u64 vs i32 vs double vs quad vs float, whatever is convenient for them. Heck, some of them will even choose different endian-ness and sometimes it will matter. I still remember the first time I dealt with a Java developer who was trying to se…

It also means you can use JSON for incredibly high precision cases by making your parser parse them into a Decimal format. You couldn’t do this if you specified these limitations into the language. Edit: Omg that story. Eep. I guess if someone provided too-large numbers in a JSON format, you could use a custom parser to accept them as strings or bigints. Still, that must have not been a fun time.

Yeah I believe I hand patched Crockford’s json2 parser? It was something like that.

Re: TOML: Tom's Obvious Minimal Language

#169

Post by localghost3000 »

crabbone wrote: post #164

It's another junk format in the sea of junk formats. It sucks for describing data, its structure is too primitive, has wrong primitives, doesn't allow extension and has no mitigations for that. Essentially, it's used because it's simple to parse and there are existing parsers. But the problems it creates are very complicated. So, here's one example of a popular use-case: pyproject.toml. I mean, PyPA aren't the bright…

> It's another junk format in the sea of junk formats.

> PyPA aren't the brightest minds around, so, they've created this joke

You have some interesting and valid criticisms of the format. Why not just say them without all the harsh insulting language? Is this how you'd want someone to speak about you and/or your work?

Re: TOML: Tom's Obvious Minimal Language

#170

Post by Supermancho »

Simran-B wrote: post #147
no_wizard wrote: post #125

Earlier quoted context omitted.

Annoyingly, it also doesn't support BigInt, which would alleviate this problem in JS as well

A number in JSON can have an arbitrary number of digits, i.e. it can represent any BigInt value.

> A number in JSON can have an arbitrary number of digits, i.e. it can represent any BigInt value.

In my experience, violating type constraints causes problems in downstream systems (usually with parsing or trying to operate on invalid values).

Number, as defined by the JSON Schema spec. A 32-bit signed integer. It has a minimum value of -2,147,483,648 and a maximum value of 2,147,483,647

BigInt is defined by various (MSFT, MySQL, etc): -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807

Most systems use a JSON String for large numbers, out of necessity, not JSON Number.

Post reply on HN