On Thu, 05 Apr 2012 08:32:10 -0400, Roy Smith wrote: > In article <4f7d896f$0$29983$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > >> > You mean JSON expects a string with valid JSON? Quelle surprise. >> >> No. The surprise is that there exists a tool invented in the 21st >> century that makes a distinction between strings quoted with " and >> those quoted with '. Being used to a sensible language like Python, it >> boggled my brain the first time I tried to write some JSON and >> naturally treated the choice of quote mark as arbitrary. > > Your brain has a low boggle threshold. > > There's absolutely no reason why JSON should follow Python syntax rules.
Except for the most important reason of all: Python's use of alternate string delimiters is an excellent design, one which Javascript itself follows. http://www.javascripter.net/faq/quotesin.htm I'm not the only one who has had trouble with JSON's poor design choice: http://stackoverflow.com/a/4612914 For a 21st century programming language or data format to accept only one type of quotation mark as string delimiter is rather like having a 21st century automobile with a hand crank to start the engine instead of an ignition. Even if there's a good reason for it (which I doubt), it's still surprising. > Making it support either kind of quotes would have complicated every > JSON library in the world, for no added value. Ooooh, such complication. I wish my software was that complicated. The added value includes: * semantic simplicity -- a string is a string, regardless of which quotes are used for delimiters; * reducing the number of escaped quotes needed; * compatibility with Javascript; * robustness. As it stands, JSON fails to live up to the Robustness principle and Postel's law: Be liberal in what you accept, and conservative in what you send. http://en.wikipedia.org/wiki/Robustness_principle > Nobody should ever be hand-writing JSON So you say, but it is a fact that people do. And even if they don't hand- write it, people do *read* it, and allowing both quotation marks aids readability: "\"Help me Obiwan,\" she said, \"You're my only hope!\"" Blah. You can cut the number of escapes needed to one: '"Help me Obiwan," she said, "You\'re my only hope!"' > (just like nobody should ever be hand-writing XML). > Just use the supplied library calls and you'll never have to worry about > low-level minutia like this again. > >> It especially boggled my brain when I saw the pathetically useless >> error message generated: >> >> py> json.loads("{'test':'test'}") >> [...] >> ValueError: Expecting property name: line 1 column 1 (char 1) >> >> "Expecting property name"??? WTF??? > > One of the hardest things about writing parsers is generating helpful > error messages when things don't parse. But, it's only of value to do > that when you're parsing something you expect to be written by a human, Or when debugging a faulty or buggy generator, or when dealing with non- conforming or corrupted data. Essentially any time that you expect the error message will be read by a human being. Which is always. Error messages are for the human reader, always and without exception. If you don't expect it to be read by a person, why bother with a message? -- Steven -- http://mail.python.org/mailman/listinfo/python-list