simplejson - Project Hosting on Google Code

Today 10 hours ago r217 (tag simplejson-2.1.0rc2) committed by bob.ippolito - tag simplejson-2.1.0rc2 tag simplejson-2.1.0rc2 10 hours ago r216 (version bump to rc2) committed by bob.ippolito - version bump to rc2 version bump to rc2 10 hours ago r215 (fix Py_ssize_t converter) committed by bob.ippolito - fix Py_ssize_t converter fix Py_ssize_t converter 13 hours ago r214 (tag as simplejson-2.1.0rc1) committed by bob.ippolito - tag as simplejson-2.1.0rc1 tag as simplejson-2.1.0rc1 13 hours ago r213 (remove tag, will retag) committed by bob.ippolito - remove tag, will retag remove tag, will retag 13 hours ago r212 (incorrect decref) committed by bob.ippolito - incorrect decref incorrect decref 13 hours ago r211 (tag as simplejson-2.1.0rc1) committed by bob.ippolito - tag as simplejson-2.1.0rc1 tag as simplejson-2.1.0rc1 13 hours ago r210 (build with newer sphinx) committed by bob.ippolito - build with newer sphinx build with newer sphinx 13 hours ago r209 (tag as 2.1.0rc1) committed by bob.ippolito - tag as 2.1.0rc1 tag as 2.1.0rc1 13 hours ago r208 (officially drop py2.4 support, doc tweaks, use only py2.5+ C...) committed by bob.ippolito - officially drop py2.4 support, doc tweaks, use only py2.5+ C API officially drop py2.4 support, doc tweaks, use only py2.5+ C API 14 hours ago r207 (tweak svn:ignore) committed by bob.ippolito - tweak svn:ignore tweak svn:ignore 22 hours ago r206 (http://bugs.python.org/issue7451) committed by bob.ippolito - http://bugs.python.org/issue7451 http://bugs.python.org/issue7451 22 hours ago issue 64 (Enable default() to generate custom data) Status changed by bob.ippolito - Except for the current float repr loophole, this is intentionally disallowed and will continue to be disallowed at least with the 2.0.x and 2.1.x branches Status: WontFix Except for the current float repr loophole, this is intentionally disallowed and will continue to be disallowed at least with the 2.0.x and 2.1.x branches Status: WontFix 22 hours ago issue 70 (version 0.6c6 of setuptools no longer exists on server) Status changed by bob.ippolito - r205 Status: Fixed r205 Status: Fixed 22 hours ago r205 (http://code.google.com/p/simplejson/issues/detail?id=70) committed by bob.ippolito - http://code.google.com/p/simplejson/issues/detail?id=70 http://code.google.com/p/simplejson/issues/detail?id=70 22 hours ago r204 (missed test case) committed by bob.ippolito - missed test case missed test case 22 hours ago issue 63 (Please remove egg= for distribution) Status changed by bob.ippolito - Status: Fixed Status: Fixed 22 hours ago issue 61 (simplejson.encoder.FLOAT_REPR incorrectly handle float subcl...) Status changed by bob.ippolito - I've only heard this request once and there's at least as many people that want the current behavior so I'm going to leave it as-is. Status: WontFix I've only heard this request once and there's at least as many people that want the current behavior so I'm going to leave it as-is. Status: WontFix 22 hours ago issue 69 (Decoder decodes JSON-strings to 'str' (Issue 28 again) / do...) Status changed by bob.ippolito - r203 Status: Fixed r203 Status: Fixed 22 hours ago r203 (http://code.google.com/p/simplejson/issues/detail?id=69) committed by bob.ippolito - http://code.google.com/p/simplejson/issues/detail?id=69 http://code.google.com/p/simplejson/issues/detail?id=69 22 hours ago issue 60 (Django's SortedDict serialization) Status changed by bob.ippolito - r197 Status: Fixed r197 Status: Fixed 23 hours ago issue 66 (New encoder to make JSON that can be safely embedded within ...) Status changed by bob.ippolito - r202 Status: Fixed r202 Status: Fixed 23 hours ago r202 (http://code.google.com/p/simplejson/issues/detail?id=66) committed by bob.ippolito - http://code.google.com/p/simplejson/issues/detail?id=66 http://code.google.com/p/simplejson/issues/detail?id=66 23 hours ago r201 (encoding memoization) committed by bob.ippolito - encoding memoization encoding memoization 23 hours ago r200 (use PyIter API instead of PySequence_Fast to avoid potential...) committed by bob.ippolito - use PyIter API instead of PySequence_Fast to avoid potential threading issues use PyIter API instead of PySequence_Fast to avoid potential threading issues Yesterday 24 hours ago r199 (Use PyOS_string_to_double when available) committed by bob.ippolito - Use PyOS_string_to_double when available Use PyOS_string_to_double when available 24 hours ago r198 (update CHANGES) committed by bob.ippolito - update CHANGES update CHANGES 25 hours ago r197 (use iteritems instead of PyDict_Next (at the expense of some...) committed by bob.ippolito - use iteritems instead of PyDict_Next (at the expense of some speed) http://bugs.python.org/issue6105 use iteritems instead of PyDict_Next (at the expense of some speed) http://bugs.python.org/issue6105 Last 30 days Dec 10, 2009 issue 70 (version 0.6c6 of setuptools no longer exists on server) reported by elias.showk - What steps will reproduce the problem? 1. sudo python setup.py install What is the expected output? What do you see instead? default version 0.6c6 of setuptools no longer exists on server http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c6-py2.6.egg What version of the product are you using? On what operating system? Version 2.1.0 Please provide any additional information below. works fine replacing default value: use_setuptools(version='0.6c11') What steps will reproduce the problem? 1. sudo python setup.py install What is the expected output? What do you see instead? default version 0.6c6 of setuptools no longer exists on server http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c6-py2.6.egg What version of the product are you using? On what operating system? Version 2.1.0 Please provide any additional information below. works fine replacing default value: use_setuptools(version='0.6c11') Dec 08, 2009 issue 34 (Proper support for serializing decimals) commented on by tfmorris - Concerning "JavaScript uses IEEE double for Number, always has, always will." in comment 10 (Bob Ippolito) - it's not clear that it "always will." In addition to the fact that "always" is an awful long time, decimal number representation and computation is a known area of shortcoming in Javascript/ECMAscript. For an interesting discussion of some of the standards work in this area, see the transcript of Doug Crockford's presentation at http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state where he spends the whole middle portion of the talk discussing this bug. Unfortunately, it doesn't look like it's going to get fixed in the next release of the standard, so the current workarounds are going to have to suffice for at least a few more years. Concerning "JavaScript uses IEEE double for Number, always has, always will." in comment 10 (Bob Ippolito) - it's not clear that it "always will." In addition to the fact that "always" is an awful long time, decimal number representation and computation is a known area of shortcoming in Javascript/ECMAscript. For an interesting discussion of some of the standards work in this area, see the transcript of Doug Crockford's presentation at http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state where he spends the whole middle portion of the talk discussing this bug. Unfortunately, it doesn't look like it's going to get fixed in the next release of the standard, so the current workarounds are going to have to suffice for at least a few more years. Dec 08, 2009 issue 34 (Proper support for serializing decimals) commented on by b...@pragmar.com - in reference to mmoedt's solution - I needed one slight modification needed to get it working - basically it needs a reference to an instance [DjangoJSONEncoder()] rather than the class itself. Hope this helps. def jsonEncode( obj ): return simplejson.dumps( obj, indent=4, default=DjangoJSONEncoder.default ) changed to: def jsonEncode( obj ): return simplejson.dumps( obj, indent=4, default=DjangoJSONEncoder().default ) in reference to mmoedt's solution - I needed one slight modification needed to get it working - basically it needs a reference to an instance [DjangoJSONEncoder()] rather than the class itself. Hope this helps. def jsonEncode( obj ): return simplejson.dumps( obj, indent=4, default=DjangoJSONEncoder.default ) changed to: def jsonEncode( obj ): return simplejson.dumps( obj, indent=4, default=DjangoJSONEncoder().default ) Dec 08, 2009 issue 43 (simplejson.loads(UNICODE FLOAT WITH MORE THAN ONE FRACTIONAL...) commented on by bob.ippolito - I've been busy. I'm going to try and do a release by the end of the year, but I'm not making any promises. I've been busy. I'm going to try and do a release by the end of the year, but I'm not making any promises. Dec 08, 2009 issue 43 (simplejson.loads(UNICODE FLOAT WITH MORE THAN ONE FRACTIONAL...) commented on by caraldi - Why not make a release? I'm hitting this bug with version 2.0.9 from the Debian and Ubuntu packages, and it appears that there is no release since march. Thanks in advance! Why not make a release? I'm hitting this bug with version 2.0.9 from the Debian and Ubuntu packages, and it appears that there is no release since march. Thanks in advance! Dec 07, 2009 issue 58 (ez_setup.py not included when running python setup.py sdist) Status changed by bob.ippolito - r196 Status: Fixed r196 Status: Fixed Dec 07, 2009 r196 (http://code.google.com/p/simplejson/issues/detail?id=58) committed by bob.ippolito - http://code.google.com/p/simplejson/issues/detail?id=58 http://code.google.com/p/simplejson/issues/detail?id=58 Nov 28, 2009 issue 69 (Decoder decodes JSON-strings to 'str' (Issue 28 again) / do...) reported by r.koeb...@yahoo.de - As mentioned in Issue 28 , newer simplejson-decoders (e.g. 2.0.9) now normally decode JSON-strings to 'str' instead of 'unicode', and only use 'unicode', when non-ASCII-characters are involved. Older versions (e.g. 1.9.2) always returned 'unicode'. But the simplejson-documentation (e.g. in the docstrings) still claims that JSON-strings are translated to 'unicode'. So: - The documentation should be fixed. - It would be useful to add an additional parameter "all_unicode" to the decoders, e.g. like in cjson.decode. As mentioned in Issue 28 , newer simplejson-decoders (e.g. 2.0.9) now normally decode JSON-strings to 'str' instead of 'unicode', and only use 'unicode', when non-ASCII-characters are involved. Older versions (e.g. 1.9.2) always returned 'unicode'. But the simplejson-documentation (e.g. in the docstrings) still claims that JSON-strings are translated to 'unicode'. So: - The documentation should be fixed. - It would be useful to add an additional parameter "all_unicode" to the decoders, e.g. like in cjson.decode. Earlier this year Nov 17, 2009 issue 68 (Decoding hooks) commented on by bob.ippolito - There's plenty of ways around that... {"__type__": "array_of_decimal", "data": "1.2 1.3 1.4"} {"__types__": {"weight": "Decimal"}, "data": [{"weight": "1.1", "name": "w1"}, {"weight": "1.2", "name": "w2"}]} There's plenty of ways around that... {"__type__": "array_of_decimal", "data": "1.2 1.3 1.4"} {"__types__": {"weight": "Decimal"}, "data": [{"weight": "1.1", "name": "w1"}, {"weight": "1.2", "name": "w2"}]} Nov 17, 2009 issue 68 (Decoding hooks) commented on by vinay_sa...@yahoo.co.uk - Ok, how do I serialize an array which contains e.g. Decimal or datetime? I don't see object_hook being called from JSONArray which AFAICT builds the array. I'm already aware that I could serialize datetimes and Decimals as dicts with a special schema (to disambiguate from actual dicts) but I was hoping to avoid this because for large datasets it makes the serialized form unnecessarily verbose. Still, wontfix is your prerogative :-( Ok, how do I serialize an array which contains e.g. Decimal or datetime? I don't see object_hook being called from JSONArray which AFAICT builds the array. I'm already aware that I could serialize datetimes and Decimals as dicts with a special schema (to disambiguate from actual dicts) but I was hoping to avoid this because for large datasets it makes the serialized form unnecessarily verbose. Still, wontfix is your prerogative :-( Nov 17, 2009 issue 68 (Decoding hooks) Status changed by bob.ippolito - Or you could serialize custom objects using... an object, and then you can use object_hook. Status: WontFix Or you could serialize custom objects using... an object, and then you can use object_hook. Status: WontFix Nov 17, 2009 issue 68 (Decoding hooks) reported by vinay_sa...@yahoo.co.uk - Although custom serialization is supported through overriding default() in a JSONEncoder, analogous support for decoding appears to be absent. The object_hook and object_pairs_hook are not, for example, called when processing arrays. Given that any custom serialization of arbitrary types not part of JSON - e.g. instances of Decimal or datetime - will be done by encoding as a string, it would be very helpful to have a hook on string scanning. For example, every string scanned in during decoding could be passed through a string_hook where specified. The hook would take a string and return either it or a custom object (e.g. Decimal, datetime instances) derived from it using custom logic. Although custom serialization is supported through overriding default() in a JSONEncoder, analogous support for decoding appears to be absent. The object_hook and object_pairs_hook are not, for example, called when processing arrays. Given that any custom serialization of arbitrary types not part of JSON - e.g. instances of Decimal or datetime - will be done by encoding as a string, it would be very helpful to have a hook on string scanning. For example, every string scanned in during decoding could be passed through a string_hook where specified. The hook would take a string and return either it or a custom object (e.g. Decimal, datetime instances) derived from it using custom logic. Nov 15, 2009 issue 67 (Speedup module does not always decode JSON strings into unic...) commented on by tlaurinolli - Then please fix the documentation to point out that JSON string may result in str. Then please fix the documentation to point out that JSON string may result in str. Nov 15, 2009 issue 67 (Speedup module does not always decode JSON strings into unic...) Status changed by bob.ippolito - This is expected behavior. If you want unicode output give it a unicode input string. Status: Fixed This is expected behavior. If you want unicode output give it a unicode input string. Status: Fixed Nov 15, 2009 issue 67 (Speedup module does not always decode JSON strings into unic...) reported by tlaurinolli - What steps will reproduce the problem? 1. Ensure that speedups module is in use: >>> import simplejson >>> decoder = simplejson.JSONDecoder() >>> assert decoder.parse_string.__module__ == 'simplejson._speedups' 2. Decode a simple string: >>> print decoder.decode('"foo"') What is the expected output? What do you see instead? Output is 'foo'. Expected output is u'foo'. What version of the product are you using? On what operating system? Verified on simplejson 2.0.9 fetched with easy_install on x86-Debian. Please provide any additional information below. It appears that the Python version would correctly return u'foo'. An older Debian with simplejson 1.9.2 always returns u'foo', but I'm not sure if it has any C extensions. What steps will reproduce the problem? 1. Ensure that speedups module is in use: >>> import simplejson >>> decoder = simplejson.JSONDecoder() >>> assert decoder.parse_string.__module__ == 'simplejson._speedups' 2. Decode a simple string: >>> print decoder.decode('"foo"') What is the expected output? What do you see instead? Output is 'foo'. Expected output is u'foo'. What version of the product are you using? On what operating system? Verified on simplejson 2.0.9 fetched with easy_install on x86-Debian. Please provide any additional information below. It appears that the Python version would correctly return u'foo'. An older Debian with simplejson 1.9.2 always returns u'foo', but I'm not sure if it has any C extensions. Nov 14, 2009 issue 66 (New encoder to make JSON that can be safely embedded within ...) reported by gavinpanella - Hi, I have a patch against trunk to add a JSONEncoderForHTML class: http://pastebin.ubuntu.com/318595/ From the docstring: To embed JSON content in, say, a script tag on a web page, the characters &, < and > should be escaped. They cannot be escaped with the usual entities (e.g. &) because they are not expanded within <script> tags. I'm not sure if this is always the case, but it is for Launchpad, which uses XHTML served as text/html (IIRC). Is this interesting to you to include in simplejson? Or maybe there's a better way to embed JSON in web pages? Thanks, Gavin Panella. BTW, it's also in a bzr branch on Launchpad. You can get the branch with: bzr branch lp:~allenap/simplejson/script-tags-rough-and-ready Or just see an overview at: https://code.launchpad.net/~allenap/simplejson/script-tags-rough-and-ready Hi, I have a patch against trunk to add a JSONEncoderForHTML class: http://pastebin.ubuntu.com/318595/ From the docstring: To embed JSON content in, say, a script tag on a web page, the characters &, < and > should be escaped. They cannot be escaped with the usual entities (e.g. &) because they are not expanded within <script> tags. I'm not sure if this is always the case, but it is for Launchpad, which uses XHTML served as text/html (IIRC). Is this interesting to you to include in simplejson? Or maybe there's a better way to embed JSON in web pages? Thanks, Gavin Panella. BTW, it's also in a bzr branch on Launchpad. You can get the branch with: bzr branch lp:~allenap/simplejson/script-tags-rough-and-ready Or just see an overview at: https://code.launchpad.net/~allenap/simplejson/script-tags-rough-and-ready Nov 10, 2009 issue 65 (Built-in support for custom sequences and iterables) Status changed by bob.ippolito - I suppose that could be implemented by adding a parameter that specifies a tuple of types that are allowed to be serialized as sequences to a list, but I have no plans to implement that. If you're streaming the results from the database (which you could potentially do with a good default function for pyodbc.Cursor) then the memory cost is negligible. Status: WontFix I suppose that could be implemented by adding a parameter that specifies a tuple of types that are allowed to be serialized as sequences to a list, but I have no plans to implement that. If you're streaming the results from the database (which you could potentially do with a good default function for pyodbc.Cursor) then the memory cost is negligible. Status: WontFix Nov 10, 2009 issue 65 (Built-in support for custom sequences and iterables) commented on by haridara - The default() callback is not the same, as you are forced to return a list. In the pyodbc scenario, if there are a few thousand database records to serialize, you would have to preload all the rows into a list first, and while doing so, have to convert each row into a list() as well, and then finally return the list of lists. If pyodbc.Cursor and pyodbc.Row are recognized as supported iterable and sequence types respectively, then you could avoid the cost of holding all the rows in memory at any time (thus reducing the memory requirement by a factor of 2). The default() callback is not the same, as you are forced to return a list. In the pyodbc scenario, if there are a few thousand database records to serialize, you would have to preload all the rows into a list first, and while doing so, have to convert each row into a list() as well, and then finally return the list of lists. If pyodbc.Cursor and pyodbc.Row are recognized as supported iterable and sequence types respectively, then you could avoid the cost of holding all the rows in memory at any time (thus reducing the memory requirement by a factor of 2). Nov 10, 2009 issue 65 (Built-in support for custom sequences and iterables) Status changed by bob.ippolito - This is what the "default" callback is for. Status: Invalid This is what the "default" callback is for. Status: Invalid Nov 10, 2009 issue 65 (Built-in support for custom sequences and iterables) reported by haridara - What steps will reproduce the problem? 1. Define a custom sequence class 2. Instantiate an instance of the custom sequence 3. Call dumps() or dump() for that instance. What is the expected output? What do you see instead? Expect to see the same treatment as for the built-in sequences such as list() What version of the product are you using? On what operating system? 2.0.9 Please provide any additional information below. Let us say you define a new sequence type such as this: >>> class MySeq: ... def __init__(self, len): ... self.len = len ... def __getitem__(self, i): ... if i < self.len: ... return i ... else: ... raise IndexError() ... def __len__(self): ... return self.len ... The following works fine: >>> myseq = MySeq(10) >>> list(myseq) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] But the below doesn't: >>> simplejson.dumps(myseq) Based on the same argument that a custom sequence should be treated as the built-in sequence, iterators should also be supported. This way a pyodbc cursor can be serialized without any conversions. pyodbc.Cursor is iterable while the pyodbc.Row is a sequence and neither can be serialized right away. What steps will reproduce the problem? 1. Define a custom sequence class 2. Instantiate an instance of the custom sequence 3. Call dumps() or dump() for that instance. What is the expected output? What do you see instead? Expect to see the same treatment as for the built-in sequences such as list() What version of the product are you using? On what operating system? 2.0.9 Please provide any additional information below. Let us say you define a new sequence type such as this: >>> class MySeq: ... def __init__(self, len): ... self.len = len ... def __getitem__(self, i): ... if i < self.len: ... return i ... else: ... raise IndexError() ... def __len__(self): ... return self.len ... The following works fine: >>> myseq = MySeq(10) >>> list(myseq) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] But the below doesn't: >>> simplejson.dumps(myseq) Based on the same argument that a custom sequence should be treated as the built-in sequence, iterators should also be supported. This way a pyodbc cursor can be serialized without any conversions. pyodbc.Cursor is iterable while the pyodbc.Row is a sequence and neither can be serialized right away. Oct 19, 2009 issue 5 (Support serializing decimal.Decimal instances) commented on by bob.ippolito - Practically speaking most JSON encoders and decoders use 64-bit floating point to handle the number type. simplejson currently can not produce documents that will not round-trip properly. Practically speaking most JSON encoders and decoders use 64-bit floating point to handle the number type. simplejson currently can not produce documents that will not round-trip properly. Oct 19, 2009 issue 5 (Support serializing decimal.Decimal instances) commented on by jamie.tremaine - The correct implementation of default for this would be: from decimal import Decimal import simplejson class DecimalEncoder(simplejson.JSONEncoder): def default(self, obj): if isinstance(obj, decimal.Decimal): return str(obj) return simplejson.JSONEncoder.default(self, obj) usage: >>> pi = Decimal("3.14") >>> simplejson.dumps(pi, cls=DecimalEncoder) '"3.14"' Expected behaviour: '3.14' As seen above, this does not result in a number according to the JSON specification, but a quoted string. This could be remedied by modifying default such that quoting of output would be disabled. The correct implementation of default for this would be: from decimal import Decimal import simplejson class DecimalEncoder(simplejson.JSONEncoder): def default(self, obj): if isinstance(obj, decimal.Decimal): return str(obj) return simplejson.JSONEncoder.default(self, obj) usage: >>> pi = Decimal("3.14") >>> simplejson.dumps(pi, cls=DecimalEncoder) '"3.14"' Expected behaviour: '3.14' As seen above, this does not result in a number according to the JSON specification, but a quoted string. This could be remedied by modifying default such that quoting of output would be disabled.

issue 65 (Built-in support for custom sequences and iterables) reported by haridara - What steps will reproduce the problem? 1. Define a custom sequence class 2. Instantiate an instance of the custom sequence 3. Call dumps() or dump() for that instance. What is the expected output? What do you see instead? Expect to see the same treatment as for the built-in sequences such as list() What version of the product are you using? On what operating system? 2.0.9 Please provide any additional information below. Let us say you define a new sequence type such as this: >>> class MySeq: ... def __init__(self, len): ... self.len = len ... def __getitem__(self, i): ... if i < self.len: ... return i ... else: ... raise IndexError() ... def __len__(self): ... return self.len ... The following works fine: >>> myseq = MySeq(10) >>> list(myseq) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] But the below doesn't: >>> simplejson.dumps(myseq) Based on the same argument that a custom sequence should be treated as the built-in sequence, iterators should also be supported. This way a pyodbc cursor can be serialized without any conversions. pyodbc.Cursor is iterable while the pyodbc.Row is a sequence and neither can be serialized right away.

What steps will reproduce the problem? 1. Define a custom sequence class 2. Instantiate an instance of the custom sequence 3. Call dumps() or dump() for that instance. What is the expected output? What do you see instead? Expect to see the same treatment as for the built-in sequences such as list() What version of the product are you using? On what operating system? 2.0.9 Please provide any additional information below. Let us say you define a new sequence type such as this: >>> class MySeq: ... def __init__(self, len): ... self.len = len ... def __getitem__(self, i): ... if i < self.len: ... return i ... else: ... raise IndexError() ... def __len__(self): ... return self.len ... The following works fine: >>> myseq = MySeq(10) >>> list(myseq) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] But the below doesn't: >>> simplejson.dumps(myseq) Based on the same argument that a custom sequence should be treated as the built-in sequence, iterators should also be supported. This way a pyodbc cursor can be serialized without any conversions. pyodbc.Cursor is iterable while the pyodbc.Row is a sequence and neither can be serialized right away.

Today

Yesterday

Last 30 days

Earlier this year