Python Gotcha's?

[Steven D'Aprano]

On Thu, 05 Apr 2012 08:32:10 -0400, Roy Smith wrote:

> In article <4f7d896f$0$29983$c3e8da3$5496439d at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at 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