[Web-SIG] Time a for JSON parser in the standard library?
pywebsig at xhaus.com
Wed Apr 9 20:38:29 CEST 2008
> I'm interested in whether you generally use JSON to communicate with a
> libraries are written with the assumption that they are to be used to
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
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
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.
> 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
Went out of my way to accept them, with python semantics.
interpreted "[1,2,3,]" differently as [1,2,3] and [1,2,3,null].
Although that may have changed during the meanwhilst.
> > 2. To have a native-code implementation, customised for jython.
> 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
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
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.
 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.
More information about the Web-SIG