[Web-SIG] Time a for JSON parser in the standard library?

[Alan Kennedy]

[John]
> I'm interested in whether you generally use JSON to communicate with a
> JavaScript client, or another JSON library. Both the demjson and simplejson
> libraries are written with the assumption that they are to be used to
> interact with JavaScript.

Answer #1: My motive is simply to implement the JSON spec, in a
[j|p]ythonic way. If the ideal of JSON is to be realised, then the
producer of the document is not relevant: it is only the document
itself that matters.

Answer #2: I'm working (i.e. day job) with JSON at the moment: a
javascript client talking to a java server. The JS guy had a problem
last week with a sample JSON document I gave him to prototype on. I
wrote the sample by hand (it later became my freemarker template), and
so inadvertently left in a hard-to-spot dangling comma, from all the
copying and pasting. That broke his javascript library; he solved the
problem by passing it through a PHP JSON codec on his local Apache. It
worked, i.e. his problem disappeared, but he didn't know why (the PHP
lib had eliminated the dangling comma). Which all goes to confirm,
IMHO, that you should be liberal in what you consume and strict in
what you produce.

[John]
> You mentioned in an earlier e-mail that jyson supports reading arrays with
> trailing commas -- is this intentional, or accidental? Do you read them with
> Python or JavaScript semantics?

Went out of my way to accept them, with python semantics.

Javascript semantics differ. Last time I tested, FireFox and IE
interpreted "[1,2,3,]" differently as [1,2,3] and [1,2,3,null].
Although that may have changed during the meanwhilst.

[Alan]
> > 2. To have a native-code implementation, customised for jython.

[John]
> Did you encounter any particular issues related to implementing a JSON
> library in Jython that would affect how a standard library implementation's
> API should be designed?

Jython is changing rapidly. It is evolving from a 2.2 stage ("from
__future__ import generators") to a 2.5 stage in one leap. Jython 2.5
is built with java 1.5 (1.5 is where java grew annotations and
generics). Between 2.2. and 2.5, python has grown Decimal's, generator
comprehensions, decorators, context managers, bi-directional
generators, etc. I prefer for a pure java implementation of a JSON
codec to remain flexible in terms of the way that it maps
"fundamental" JSON types into the jython type hierarchy and
interpreter machinery[1].

I'm beginning to think that any putative JSON API should permit the
user to specify which class will be used to instantiate JSON objects.
If the users can specify their own classes, that might go a long way
way resolve issues such as "I need my javascript client to communicate
Numbers representing radians to my python server which uses Decimal
because it works better with my geo-positioning library". Standard
libraries should provide their own set of default instantiation
classes, which the user could override.

Regards,

Alan.

[1] There is an argument that a pure java JSON parser for jython is
not worth the effort, in performance terms at least. JVM optimisation
is very sophisticated these days, and it is conceivable that pure
python (byte)code could run as fast or faster on a JVM than equivalent
java code. Think PyPy. So maybe a single well-designed pure-python
JSON module in the cpython standard library is the way to go.