Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

221–229 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#221

Earlier quoted context omitted.

Just to add one more feature request... ;-) Comments are preserved when you read a file, change some of its contents, and write it back out again.

I have zero issues if parsers choose to do this but I wouldn’t argue that it shouldn’t be a required part of the specification. If comments need to be preserved then they’re part of the schema and should be a (for example) string field rather than comment.

What's the connection? They can't be a string field because semantically they're tied to another field they're commenting, and they need to be preserved because that info is valuable

Why do you require conversion in this use case?

Re: TOML: Tom's Obvious Minimal Language

#224

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…

Could you list a couple of great formats? The various issues are indeed widespread across all the popular ones, and there are too many formats to find the greats (wish there were a comparison site with all the features so you could easily exclude those that fail at a specific task)

Re: TOML: Tom's Obvious Minimal Language

#225

Earlier quoted context omitted.

> 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 dam…

My claim is that you _don't_ need to be an asshole to get your point across. It sounds like your goal is to change how PyPA works/what it does. That's great! I think you will be less effective in your goals by personally insulting the individuals behind the group; regardless of whether you think that this _ought_ to be the case.

> They should be called what they are, without hesitation and euphemisms.

You disagree with decisions made by the people at PyPA. I don't think you presented any reason to believe that these people were dumb? Or that they had a low IQ? Or anything else to that extent?

You disagree with decisions, and then concluded that this _must_ make them dumb. Is it possible that they are simply making different trade-offs from you? Or that there's some (possibly mutual) misunderstanding of the problem? As another commenter has pointed out, some of your claims about the state of PyPA tooling were spurious, yet nobody would say that "you're not the brightest" because of it!

You seem like a passionate person, and I genuinely hope that you come to the conclusion that empathy (especially in technical contexts) is a better route than hurling insults. I hope that you can direct your passion to making the world a better place, rather than putting people down. The world could certainly use the help.

Re: TOML: Tom's Obvious Minimal Language

#226
post #63

Earlier quoted context omitted.

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

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.

Doesn't matter.

The baseline is anything written in C and C++, which don't have bignum or decimal types and so more or less always parse JSON numbers to either int64 or double, at best.

Re: TOML: Tom's Obvious Minimal Language

#227

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…

Let me introduce you to our lord and savior: YAML. ;)

Yaml is plain unreadable for me tho

Re: TOML: Tom's Obvious Minimal Language

#228

Earlier quoted context omitted.

> 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 gav…

[flagged]

Re: TOML: Tom's Obvious Minimal Language

#229

Earlier quoted context omitted.

This isn't right. JSON can also store exponential numbers (eg {"google": 1e+100}). You could decode this to an arbitrary-sized BigInt, but I can make you waste an arbitrary number of bytes in RAM if you do that. And even then, "look for a decimal point" doesn't give you enough information to tell whether the number is an integer. Eg, 1.1e+100 is an integer, and 1e-100 is not an integer. One of JSON's biggest benefits…

Ok so it allows e notation, but still the actual numerical value is unambiguous. You could parse that into a data structure that (for example) stores the mantissa and exponent as (arbitrarily large) integers. Again, that most languages try to shoehorn decimals into floats or whatever is on those languages.

In court you would be right, in practice it's on JSON. Requiring an arbitrary precision math library to correctly parse JSON is just not going to happen. The only language I know that even does this out of the box is Python with their automagic best numeric type. Even Ruby which is dynamic to a fault only gives arbitrary precision for integers and parses JSON numbers with decimals as floats.
Post reply on HN