On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
That sounds like a really bad idea, if there is an option to change
the behavior it shouldn't live in module state.
Would you rather have strictness controls as parameters? demjson
currently has seventeen of those. Maybe
On Wed, Apr 9, 2008 at 11:01 PM, John Millikin [EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
That sounds like a really bad idea, if there is an option to change
the behavior it shouldn't live in module state.
Would you rather have
John Millikin wrote:
On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
That sounds like a really bad idea, if there is an option to change
the behavior it shouldn't live in module state.
Would you rather have strictness controls as parameters? demjson
currently has
[Bob]
simplejson would give you an error and tell you exactly where the
problem was,
Another good point.
Other JSON modules should follow simplejson's lead, and provide access
to the location in the document where the lexical or parse error
occurred, so that the offending document can be
Bob Ippolito wrote:
On Wed, Apr 9, 2008 at 8:04 PM, John Millikin [EMAIL PROTECTED] wrote:
For exception by default behavior, the library can call
warnings.simplefilter (error, JSONWarning) on initialization. Then
we just define various subclasses of JSONWarning for the different
warning
On Wed, Apr 9, 2008 at 12:27 PM, Benji York [EMAIL PROTECTED] wrote:
Ian Bicking wrote:
parse (bytes_or_string)
generate (obj, indent = None, ascii_only = True, encoding = 'utf-8')
I strongly prefer we stick to the conventional names of
dump/dumps/load/loads, for consistency
parse (bytes_or_string)
generate (obj, indent = None, ascii_only = True, encoding = 'utf-8')
I strongly prefer we stick to the conventional names of
dump/dumps/load/loads, for consistency with other serialization
libraries already in Python.
Ian
[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
On Wed, Apr 9, 2008 at 10:05 AM, Ian Bicking [EMAIL PROTECTED] wrote:
I strongly prefer we stick to the conventional names of
dump/dumps/load/loads, for consistency with other serialization libraries
already in Python.
On Wed, Apr 9, 2008 at 10:27 AM, Benji York [EMAIL PROTECTED] wrote:
+1
[Alan]
[hand written JSON containing 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
On Wed, Apr 9, 2008 at 5:48 PM, Alan Kennedy [EMAIL PROTECTED] wrote:
[Alan]
[hand written JSON containing 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
On Wed, Apr 9, 2008 at 7:20 PM, Ian Bicking [EMAIL PROTECTED] wrote:
I prefer liberal, with an option to turn on warnings or be strict.
Potentially warnings could be turned on by default, and turned off with
the warnings module. (Is there a way to have a warning raise an
exception by
On Wed, Apr 9, 2008 at 8:04 PM, John Millikin [EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 7:20 PM, Ian Bicking [EMAIL PROTECTED] wrote:
I prefer liberal, with an option to turn on warnings or be strict.
Potentially warnings could be turned on by default, and turned off with
the
John Millikin wrote:
On Sat, Apr 5, 2008 at 7:01 PM, Robert Brewer [EMAIL PROTECTED] wrote:
Re: Representation of Fractional Numbers, there are two solutions. If you
return decimals, people using JS on the other end are going to call
float(d).
If you return floats, people not using JS on
I've written a rough draft of a PEP for standard library inclusion, attached
to this email. Comments/improvements welcome - I tried to leave most of the
differences between modules in the Issues section.
PEP: XXX
Title: A JSON handling library
Version: $Revision$
Last-Modified: $Date$
Author: John
John Millikin wrote:
I've written a rough draft of a PEP for standard library inclusion,
attached to this email. Comments/improvements welcome - I tried to
leave most of the differences between modules in the Issues section.
Re: Representation of Fractional Numbers, there are two solutions. If
(messed up CC on last email, re-sending to list)
On Sat, Apr 5, 2008 at 7:01 PM, Robert Brewer [EMAIL PROTECTED] wrote:
Re: Representation of Fractional Numbers, there are two solutions. If you
return decimals, people using JS on the other end are going to call
float(d). If you return floats,
Bob Ippolito wrote:
I chose to only support the basic types out of the box, but you can
specialize the decoder and encoder any way you want, e.g. to provide a
JSON serialization scheme where you get a deque out if you put one in.
I can imagine scenarios where you would want to encode decimal
Bob and John, I downloaded the new versions of simplejson (1.8.1)
and jsonlib (1.2.7). I will re-run tests and update my report
at http://deron.meranda.us/python/comparing_json_modules/
over the next couple days. I went ahead and put a note on
there that new versions are available; until I get
I've added a few issues to your tracker, regarding encoding
autodetection, support for serializing stdlib classes like
collections.deque and decimal.Decimal, and a unittest test suite.
There don't seem to be any downloads of simplejson available at
On Sun, Mar 16, 2008 at 7:18 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm reading Alan's post as saying that he has a competing implementation.
Yes, there are several JSON implementation now, some
better than others.
I finally sat down and put the five or so top JSON libraries
to the test
On Thu, Mar 20, 2008 at 1:37 PM, Deron Meranda [EMAIL PROTECTED] wrote:
On Sun, Mar 16, 2008 at 7:18 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm reading Alan's post as saying that he has a competing implementation.
Yes, there are several JSON implementation now, some
better than
On Thu, Mar 20, 2008 at 12:37 PM, Deron Meranda [EMAIL PROTECTED] wrote:
I finally sat down and put the five or so top JSON libraries
to the test so we can all see what's what. I've put everything
in a report here:
http://deron.meranda.us/python/comparing_json_modules/
This is
On Thu, Mar 20, 2008 at 3:38 PM, Deron Meranda [EMAIL PROTECTED] wrote:
On Thu, Mar 20, 2008 at 6:03 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
On Thu, Mar 20, 2008 at 1:37 PM, Deron Meranda [EMAIL PROTECTED] wrote:
I finally sat down and put the five or so top JSON libraries
to the
On Thu, Mar 20, 2008 at 7:50 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
Anyway, to get JSON in UTF-8, I'm calling it like this:
simplejson.dumps( [\x1a], ensure_ascii=False ).encode('utf8')
which on my system outputs this: '[\x1a]'
rather than this: '[\\u001a]'
If I
On Thu, Mar 20, 2008 at 6:48 PM, John Millikin [EMAIL PROTECTED] wrote:
This is fantastic. My knowledge of other JSON modules was based mainly
on the comparison page from json.org, and yours is much more complete
and informative.
Well that's understandable. What's on json.org is great to
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
On 11/03/2008, Alan Kennedy [EMAIL PROTECTED] wrote:
[Graham]
The problem areas were, different interpretations of what could be
supplied in an error response. Whether an integer, string or arbitrary
object could be supplied as the id attribute in a request. Finally,
some
[Massimo]
It would also be nice to have a common interface to all modules that
do serialization. For example pickle, cPickle, marshall has dumps, so
json should also have dumps.
Indeed, this is my primary concern also.
The reason is that I have a pure-java JSON codec for jython, that I
will
[Graham]
The problem areas were, different interpretations of what could be
supplied in an error response. Whether an integer, string or arbitrary
object could be supplied as the id attribute in a request. Finally,
some JavaScript clients would only work with a server side
implementation
Dear all,
Given that
1. Python comes with batteries included
2. There is a standard library re-org happening because of Py3K
3. JSON is now a very commonly used format on the web
Is it time there was a JSON codec included in the python standard library?
(If XML is already supported, I see no
Is it time there was a JSON codec included in the python standard library?
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by TurboGears, Pylons, and bundled with Django.
Choosing a Python JSON
On 10.03.2008, at 14:37, Mark Ramm wrote:
Is it time there was a JSON codec included in the python standard
library?
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by TurboGears, Pylons, and bundled
On Mon, 10 Mar 2008 09:37:35 -0400, Mark Ramm
[EMAIL PROTECTED] said:
Is it time there was a JSON codec included in the python standard library?
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by
On Mon, Mar 10, 2008 at 9:08 AM, Jonathan Ellis
[EMAIL PROTECTED] wrote:
On Mon, 10 Mar 2008 09:37:35 -0400, Mark Ramm
[EMAIL PROTECTED] said:
Is it time there was a JSON codec included in the python standard
library?
I would definitely support the incusion of a JSON library in the
I agree. simplejson is used by web2py as well.
Massimo
On Mar 10, 2008, at 8:37 AM, Mark Ramm wrote:
Is it time there was a JSON codec included in the python standard
library?
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be
On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm [EMAIL PROTECTED] wrote:
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by TurboGears, Pylons, and bundled with Django.
I'd tentatively agree, though I recall
On Mon, Mar 10, 2008 at 7:23 PM, James Bennett [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm [EMAIL PROTECTED] wrote:
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by
On 11/03/2008, James Bennett [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm [EMAIL PROTECTED] wrote:
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by TurboGears, Pylons, and
Well, so fix this. How hard can it be?
A google search for jsonlib rfc turns up this article:
http://jmillikin.blogspot.com/2008/02/python-json-catastrophe.html
And it looks like the two issues with simplejson are:
1) decoding JSON with unicode code-points outside the Basic Multilingual
It would also be nice to have a common interface to all modules that
do serialization. For example pickle, cPickle, marshall has dumps, so
json should also have dumps.
Massimo
On Mar 10, 2008, at 9:51 PM, Mark Ramm wrote:
Well, so fix this. How hard can it be?
A google search for
On Mon, Mar 10, 2008 at 11:55:04PM -0500, Massimo Di Pierro wrote:
- It would also be nice to have a common interface to all modules that
- do serialization. For example pickle, cPickle, marshall has dumps, so
- json should also have dumps.
Doesn't it? Or did you want something additional?
42 matches
Mail list logo
