[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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
