It could look like this:

the propos delet,the proposed deletion,3590,7180.0,the proposed deletion,7153.333333333333,the proposed deletions,13.666666666666666,The proposed deletion,12.0,the proposed deletes,1.0

And that is it — this will be the most compact storage data format, because all the repeated data, that describes the structure of the dicts and lists inside a term will be contained in the code that will parse this. I believe that this might be faster than json read function.

I’m the author of jsonlib, and I registered specifically to post this message. Please, please, please do not use cjson!

First, it is unmaintained. The latest version available was posted on August 24, 2007. When you encounter one of its myriad bugs, you’ll either have to patch it yourself or pick another JSON library. Just skip the intermediate step and use another library to begin with.

Second, it is buggy. In some cases, parsing text it just generated will return a different value from what you passed in! It’s almost entirely ignorant of Unicode, and what little it tries to parse it gets wrong.

Third, it’s exceedingly non-compliant. The text it parses and generates bears only a passing resemblance to JSON. There are varying degrees of conformance to the spec between libraries, based on personal preference of the authors — I prefer strict conformance, others less strict — but cjson is so different as to be simply unusable.

Yes, it’s fast. I know. I wrote jsonlib partly because I was unsatisfied with simplejson’s performance, and one goal (never truly achieved) was always to surpass cjson. However, speed isn’t everything. As the saying goes, “if I want my math performed fast and wrong I’ll ask my cat”.

In my opinion, the only Python JSON libraries worth considering are:

* simplejson — it’s in the standard library, and should therefore be considered first and most thoroughly.

* jsonlib — it’s fast, well-tested, and standards-compliant.

* demjson — has several options for reliable parsing of invalid input.

Last time I checked, jsonlib and simplejson’s C extensions are neck-and-neck performance-wise. In some quick, unscientific tests, jsonlib reads faster and simplejson writes faster. However, simplejson’s extensions are only used for certain subsets of input — if you want to use an uncommon feature, performance will degrade. jsonlib has an implementation in pure C, which avoids this problem at the cost of complexity.

Apologies for the brain-dump, but even if you skip right over it, please remember: don’t use cjson.

I’m the author of jsonlib, and I registered specifically to post this message. Please, please, please do not use cjson!

First, it is unmaintained. The latest version available was posted on August 24, 2007. When you encounter one of its myriad bugs, you’ll either have to patch it yourself or pick another JSON library. Just skip the intermediate step and use another library to begin with.

Second, it is buggy. In some cases, parsing text it just generated will return a different value from what you passed in! It’s almost entirely ignorant of Unicode, and what little it tries to parse it gets wrong.

Third, it’s exceedingly non-compliant. The text it parses and generates bears only a passing resemblance to JSON. There are varying degrees of conformance to the spec between libraries, based on personal preference of the authors — I prefer strict conformance, others less strict — but cjson is so different as to be simply unusable.

Yes, it’s fast. I know. I wrote jsonlib partly because I was unsatisfied with simplejson’s performance, and one goal (never truly achieved) was always to surpass cjson. However, speed isn’t everything. As the saying goes, “if I want my math performed fast and wrong I’ll ask my cat”.

In my opinion, the only Python JSON libraries worth considering are:

* simplejson — it’s in the standard library, and should therefore be considered first and most thoroughly.

* jsonlib — it’s fast, well-tested, and standards-compliant.

* demjson — has several options for reliable parsing of invalid input.

Last time I checked, jsonlib and simplejson’s C extensions are neck-and-neck performance-wise. In some quick, unscientific tests, jsonlib reads faster and simplejson writes faster. However, simplejson’s extensions are only used for certain subsets of input — if you want to use an uncommon feature, performance will degrade. jsonlib has an implementation in pure C, which avoids this problem at the cost of complexity.

Apologies for the brain-dump, but even if you skip right over it, please remember: don’t use cjson.

Compactness is very important for transferring data over a network.
However, during the development cycle, human readability is important and often overlooked. If all you need to do to read your data is type ‘zcat’, you are much more likely to be looking at your data, and hence more likely to catch bugs.

I still have high hopes for protobuf: it can get faster, but json can’t get any smaller. At some point protobuf will be both the fastest and most compact method.