[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. _______________________________________________ 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