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

[John Millikin]

I am the author of jsonlib. Apologies for not replying to this thread
earlier; I had not realized that JSON was considered a web-side
technology, as I use it primarily for serialization of simple data
sets between Python, Java, and C. First, I would like to state that my
purpose for writing jsonlib was not to become the maintainer of yet
another (de)serializer, but merely to solve my immediate problem of no
JSON libraries that handle Unicode correctly. Any solution that
results in a standard JSON library I fully support. At the worst, if
Python decides to go down the route of the super-forgiving parsers I
will simply maintain jsonlib as a separate library.

> I think the author could very well be incorrect in believing that the
> spec requires using a decimal
>
The spec does not require a decimal, but I dislike losing information
in the parsing stage. Any implementation in the standard library
should, in my opinion, at least offer a parameter for lossless parsing
of number values.

> On the encoding side, I simply make the assumption that all character
> transcoding has happened before the JSON text reaches the JSON parser.
> (I think this is a reasonable assumption, given that byte streams are
> always associated with file storage, network transmission, etc, and
> only the programmer has access to the relevant encoding information).
> But given that RFC 4627 specifies how to guess encoding of JSON byte
> streams, I'll probably change that policy.
>
jsonlib has an encoding autodetection feature. It's not particularly
hard, except that Python 2.5 (the version I use) does not have a codec
for UTF-32, so I had to hand-roll one using the struct module.

Finally, as regards APIs, I very much like the simplejson API and have
attempted to model the options of jsonlib's write() function after
simplejson's dumps. My reason for using read() and write() is due to
python-json, which is the first JSON library I used.