6 ms·

Honestly, I dont see the issue with JSON. It is capturing user generated content. It's not that '43' is a logged as a string instead of an int - it is that '43

Honestly, I dont see the issue with JSON. It is capturing user generated content. It's not that '43' is a logged as a string instead of an int - it is that '43' is the raw data in quotes. To me, that is the same spirit as using "read" instead of "eval" as mentioned elsewhere. Yes the read-print-loop fails for JSON - but JSON only has this failing when you are working with code-generated values. At the end of the day - a user type the 4 and 3 keys on their keyboard and that was captured. To say it is an int or a str or whatever brings back the need to understand memory representations. for example - when parsing json with python, you can apply the same principles you would to python objects. That is, assume the item is the format you know it should be (or test it first to be safe) so even though the json is {'43' : ['bob','alice']} - you can do an int() cast if you need to do something with that data that requires it to have a type. Otherwise it is represented as it was typed. I do agree with the article overall though!

joshlemer 4y ago
So, JSON has non-string values in other positions (as elements of arrays, or values in an object). Wouldn't your argument also lead to the conclusion that we don't need numbers at all, since we could get by with { "foo": "42", "bar": ["1", "2", "3"] } There's also the issue of values with multiple equivalent string representations. I want 42.1 to equal 42.10 and 42.100. I also want {"foo":1,"bar":2} to equal {"bar":2,"foo":1} but with just strings you don't get that: { "{\"foo\":1,\"bar\":2}": 1, "{\"bar\":2,\"foo\":1}": 1, "42.1": 2, "42.10": 2, "42.100": 2 } should have 2 keys but has 5
- cupofpython 4y ago
  > { "foo": "42", "bar": ["1", "2", "3"] } Good point, we could also expect {"foo": "42", "bar": "[1,2,3]"}. JSON does assume that the values have types (like a list) and that is inconsistent. As for equivalent representations, I do not think what you want is universally applicable. 42.1 does not equal 42.10 until you use logic to rule that what you are working with are Numbers In government regulations related text, for example, 42.10 could be 9 items after 42.1 and you might expect to see 42.1(a) and 42.10(a) as other items in the same set or related value sets. Any way you cut it, the real problem seems to be that when data entry happens - a certain amount of context is assumed - and those assumptions have enough variance to need to be handled differently when the data is consumed. Which makes sense

joshlemer 4y ago

So, JSON has non-string values in other positions (as elements of arrays, or values in an object). Wouldn't your argument also lead to the conclusion that we don't need numbers at all, since we could get by with { "foo": "42", "bar": ["1", "2", "3"] } There's also the issue of values with multiple equivalent string representations. I want 42.1 to equal 42.10 and 42.100. I also want {"foo":1,"bar":2} to equal {"bar":2,"foo":1} but with just strings you don't get that: { "{\"foo\":1,\"bar\":2}": 1, "{\"bar\":2,\"foo\":1}": 1, "42.1": 2, "42.10": 2, "42.100": 2 } should have 2 keys but has 5

cupofpython 4y ago
> { "foo": "42", "bar": ["1", "2", "3"] } Good point, we could also expect {"foo": "42", "bar": "[1,2,3]"}. JSON does assume that the values have types (like a list) and that is inconsistent. As for equivalent representations, I do not think what you want is universally applicable. 42.1 does not equal 42.10 until you use logic to rule that what you are working with are Numbers In government regulations related text, for example, 42.10 could be 9 items after 42.1 and you might expect to see 42.1(a) and 42.10(a) as other items in the same set or related value sets. Any way you cut it, the real problem seems to be that when data entry happens - a certain amount of context is assumed - and those assumptions have enough variance to need to be handled differently when the data is consumed. Which makes sense