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

[Alan Kennedy]

[Deron]
> (I just joined this list, so this reponse may not be threaded properly)

[Bob]
> I wasn't subscribed to the list at the time this came up, but I'm all
> for getting simplejson into the stdlib.

Well, it appears we have a quorum of JSON<->python codec writers,
since I've written a jython module that I'd like to interoperate with
cpython codecs. I think it's appropriate for any discussions of JSON
to take place on the web-sig.

I've been thinking about how to take this forward. I see two ways

Formal approach
============

Introduce a "Standards Track" Library PEP, which is designed for the
purpose of bringing a new module through a full peer-review process
and into the python standard library. (Which means we in jython and
ironpython land should also then provide it). This would have the
following outcomes

 - Result in a single JSON implementation going into the cpython
standard library, possibly in Python 3000
 - Expose the new module to full community review/bug-tracking/modification
 - Opportunity to thrash out all of the finer points of JSON<->python
transcoding, including but not limited to
  - NaN, Infinity, etc
  - What is the most appropriate number/integer/float/double/decimal
representation
  - Structural strictness, e.g. junk after document body, dangling commas, etc.
  - BMP support
  - Byte encoding detection
  - Python 3000 support
 - Standardise the interface, de facto

However, this option is somewhat complicated by the fact that we seem
to have TWO quality cpython implementations competing for a place in
the cpython standard library. Also, I think the PEP process might be a
little cumbersome for this topic, given that the PEP process involves
commit rights to the cpython source tree (since the proposal for a new
module should be accompanied by the source code of the proposed
implementation).

Informal approach
=============

Develop and document a standard interface, and ensure that all of our
modules support it. This interface would define method, class and
exception names. Standard methods would probably "load" and "dump"
objects, possibly creating "JSONEncoder"s and "JSONDecoder"s to do the
job: "JSONException" and subclasses thereof would signify errors.
Perhaps a standard mechanism to retrieve the location of errors, e.g.
line and column, would be appropriate? Perhaps a standard set of
feature/option names could be agreed, e.g. "accept_NaN", etc.

User code written to this standard could move reasonably easily
between implementations, or indeed between platforms. This approach
has the benefits that

 - Authors are free to interpret edge cases as they see fit, and
provide options.
 - Competing implementations can continue to improve in the field
 - Changing implementations could be as simple as using a different egg
   (Although an exhaustive set of test cases covering the required
behaviour is recommended)

We could call it PAJ, Python Api for Json, or some such.

I feel the informal option is more appropriate. It could be
effectively managed on a wiki page. Or perhaps a ticketing system
(e.g. TRAC) would be good for tracking detailed discussions of JSON's
many edge cases, etc. I would be willing to start a wiki page with
details about a putative module interface.

Finally, at this stage I think speed is less of a concern; correctness
is more important for now. As Aahz is fond of quoting, "It is easier
to optimize correct code than to correct optimized code".

Thoughts?

Alan.