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

211–220 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#211

Post by rob »

bruce511 wrote: post #5

I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…

At work, we needed a config file for some employees to sit alongside a custom (non-web) script I wrote. These employees have zero technical knowledge (like, they wouldn't know basic HTML), and I found TOML to be pretty easy for them to understand. It looks like this:

    # config.toml

    [[podcasts]]
    title="Podcast 1"
    export_label="Label 1"

    [[podcasts]]
    title="Podcast 2"
    export_label="Label 2"
It's flat for them, but gives me a nice `$podcasts` array of nested objects to work with and they don't need to worry about curly braces, indenting, etc. They can just copy/paste three lines if they need to "add" a new one.

Of course, my use case is pretty simple and these are simple string values, but I found it pretty nice.

Re: TOML: Tom's Obvious Minimal Language

#212

Post by ghusbands »

Supermancho wrote: post #170
Simran-B wrote: post #147

Earlier quoted context omitted.

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…

In context, BigInt refers to arbitrary precision integers [1], rather than any particular size of integer, hence "arbitrary number of digits".

[1] https://v8.dev/features/bigint

Re: TOML: Tom's Obvious Minimal Language

#213

Post by enriquto »

rfoo wrote: post #209
enriquto wrote: post #158

Earlier quoted context omitted.

just use longer keys (with an ad-hoc separator, if you want)

What about lists? Something like: --allowed-downtime-0-start=20230523170000Z --allowed-downtime-0-end=20230523170500Z --allowed-downtime-1-start=... Or --allowed-downtime-start='20230523170000Z,...' I can live with them, but neither looks clean :( Genuine question, as I actually like the plain old flagfiles/Java-properties-ish style.

The output produced by gron looks quite clean to me. You just write your file as if it was a list of js variable assignments.

    allowed-downtime[0][0] = 20230523170000Z
    allowed-downtime[0][1] = 20230523170500Z
    allowed-downtime[1][0] = ...
or if you absolutely want the names, you can make a "list of dictionaries":

    allowed-downtime[0].start = ...

Re: TOML: Tom's Obvious Minimal Language

#214

Post by riffraff »

debugnik wrote: post #176
riffraff wrote: post #67

Earlier quoted context omitted.

The norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.

Could you explain further? The link contradicts this: > The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.

the article is wrong, from what I can tell.

From https://yaml.org/spec/1.2.2/ext/changes/

> Changes in version 1.2 (revision 1.2.0) (2009-07-21)

> [...]

> Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings. Underlines _ cannot be used within numerical values.

Re: TOML: Tom's Obvious Minimal Language

#215

Post by crabbone »

localghost3000 wrote: post #169
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?

I don't care what kind of language people use when they speak about me.

Also, I select what to say to say precisely what I want. Junk is something that is likely of poor quality, old and broken and therefore discarded, useless. This perfectly describes what TOML, JSON, YAML and the rest in the sea of junk formats are.

PyPA are awful at doing their only job: defining rules for Python packaging. In the post above I gave one illustration of the poor quality of their work. Something that could've been easily prevented had they applied themselves to critically assessing the outcomes of their work. And, if need be, I can find a dozen of examples of the same, and probably more. And they don't work in isolation, even in Python world the problem of packaging Python code is not unique to them. They can be compared oranges-to-oranges with other similar efforts. And, yes, they aren't the brightest by a wide margin. And they should be told about it, because they self-selected to handle the problem plenty of people who didn't nominate them for that role depend on in their daily lives. It's a moral duty of anyone who understands how bad they are to repeatedly remind them about it.

Re: TOML: Tom's Obvious Minimal Language

#216

Post by crabbone »

3193528104 wrote: post #171
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…

> I mean, PyPA aren't the brightest minds around You don't need to be an asshole to get your message across.

I don't care if I'm an asshole. The subject is PyPA's incompetence. And I don't see any point of tiptoeing around this fact. PyPA self-selected to handle the task they aren't up to. They keep doing it despite repeatedly failing at it. And they would not relinquish the power, nor would they listen to the criticism.

Regardless of whether I am an asshole or not, the impact of my actions is negligible compared to the damage PyPA has done and keeps doing to the very thing they are meant to support. They should be called what they are, without hesitation and euphemisms. This is the right thing to do.

Re: TOML: Tom's Obvious Minimal Language

#217

Post by crabbone »

jborean93 wrote: post #166
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…

Even in your list, there's a problem. I'll describe it first, and then will get to the one I had in mind when I gave my example.

It's common that your build requirements and your runtime requirements have a big overlap that has to iterate together. Here's a realistic example: NumPy comes with various build helpers that you need at build time, if you are making a native module. So, you need to depend on a particular version of NumPy both during the build and at runtime.

In other words, you would want to be able to reference the same package + version in two places.

You could say that this is a problem with "specific" package, where the developers didn't care to separate two kinds of requirements... and in some sense you are right... but: there is a value to having build helpers and the rest of the runtime code in the same package. It's simpler. It prevents those using your package from accidentally messing up.

Finally, it's NumPy we are talking about, it's not a "specific" package... it's like 50% of the entire Python ecosystem.

---

Now, to what I mean in my example.

This is taken verbatim from "real Python" site for the lack of a better example:

    # pyproject.toml
    
    [tool.poetry]
    name = "rp-poetry"
    version = "0.1.0"
    description = ""
    authors = ["Philipp "]
    
    [tool.poetry.dependencies]
    python = "^3.9"
    
    [tool.poetry.dev-dependencies]
    pytest = "^5.2"
    
    
    [build-system]
    requires = ["poetry-core>=1.0.0"]
    
    build-backend = "poetry.core.masonry.api"
See how "python = ^3.9" is a dependency of Poetry? But what if I also want to make my project build with setuptools? Setuptools also depends on Python... where would I put that now? Not under [tool.setuptools.dependencies]? What do you think?

Re: TOML: Tom's Obvious Minimal Language

#218

Post by himujjal »

conaclos wrote: post #27

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…

Hi. I am the author of EKON. I realized YAML was doing too many things. EKON was meant to be an extension of JSON5. Although right now I realise its also doing too many stuffs under the hood.

I should rewrite the project again. But be as simple as possible.

That was my first C project ever during my University. :P

Re: TOML: Tom's Obvious Minimal Language

#219

Post by eviks »

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

still won't be prefect, all those extra quotes are bad for a heavily used human readable configs format

Re: TOML: Tom's Obvious Minimal Language

#220

Post by eviks »

bdudbdjsh wrote: post #44
arp242 wrote: post #16

Earlier quoted context omitted.

That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904

published data standards having version is so wrong. now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all. all this is so silly. we will stick with json and infor…

Since it's impossible to design anything great in tech on first attempt, what is the road to improvement without versions?

(and mentioning version could be a requirement in a future version)

Post reply on HN