<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: simplejson 1.7</title>
	<atom:link href="http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/feed/" rel="self" type="application/rss+xml" />
	<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/</link>
	<description>Bob's Rants</description>
	<pubDate>Fri, 05 Sep 2008 21:32:35 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: noname</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11728</link>
		<dc:creator>noname</dc:creator>
		<pubDate>Sun, 18 Nov 2007 10:05:57 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11728</guid>
		<description>* Tried cygwin gcc; compiled fine, but "python setup.py install" compailed about VS2003.
* Followed instructions posted at 
http://python.cx.hu/python-cjson/#win32
compiled fine with mingw32 gcc but "python setup.py install" compailed about VS2003.
* installed VS2005, "python setup.py install" compailed about VS2003.
* tried "python setup.py install -c mingw32" but returned unknown cmd

changed "    standard=True" line in setup.py to "    standard=False", and simplejson installed fine. (without speed-ups, anyways).</description>
		<content:encoded><![CDATA[<p>* Tried cygwin gcc; compiled fine, but &#8220;python setup.py install&#8221; compailed about VS2003.<br />
* Followed instructions posted at<br />
<a href="http://python.cx.hu/python-cjson/#win32" rel="nofollow">http://python.cx.hu/python-cjson/#win32</a><br />
compiled fine with mingw32 gcc but &#8220;python setup.py install&#8221; compailed about VS2003.<br />
* installed VS2005, &#8220;python setup.py install&#8221; compailed about VS2003.<br />
* tried &#8220;python setup.py install -c mingw32&#8243; but returned unknown cmd</p>
<p>changed &#8221;    standard=True&#8221; line in setup.py to &#8221;    standard=False&#8221;, and simplejson installed fine. (without speed-ups, anyways).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: henk-jan</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11621</link>
		<dc:creator>henk-jan</dc:creator>
		<pubDate>Sat, 20 Oct 2007 19:14:05 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11621</guid>
		<description>Is there a way to recieve a json number either as type Decimal or s ating (floats have thier own problems)?

kind regards
Henk-Jan</description>
		<content:encoded><![CDATA[<p>Is there a way to recieve a json number either as type Decimal or s ating (floats have thier own problems)?</p>
<p>kind regards<br />
Henk-Jan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesus Rodriguez</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11602</link>
		<dc:creator>Jesus Rodriguez</dc:creator>
		<pubDate>Tue, 16 Oct 2007 14:23:46 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-11602</guid>
		<description>I've been trying to figure out what changed between 1.3 and 1.7 with respect to object_hook and loads. In 1.3 the object_hook would get called once with my entire complex object, I could then return the appropriate python objects.  In 1.7, all the dicts are passed in separately causing object_hook to be called n times where n is the number of {} found.

Take for instance the following string: 
'{"foobar":"baz","comp":{"key":10},"array":[10,20,30]}'

1.3 would pass the above string into the object_hook as is. With 1.7 the following happens:
first {u'key': 10} is passed in, then {u'foobar': u'baz', u'array': [10, 20, 30], u'comp': None} is passed in.

Was this change intentional? or was it a side-effect of switching from sre to re?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been trying to figure out what changed between 1.3 and 1.7 with respect to object_hook and loads. In 1.3 the object_hook would get called once with my entire complex object, I could then return the appropriate python objects.  In 1.7, all the dicts are passed in separately causing object_hook to be called n times where n is the number of {} found.</p>
<p>Take for instance the following string:<br />
&#8216;{&#8221;foobar&#8221;:&#8221;baz&#8221;,&#8221;comp&#8221;:{&#8221;key&#8221;:10},&#8221;array&#8221;:[10,20,30]}&#8217;</p>
<p>1.3 would pass the above string into the object_hook as is. With 1.7 the following happens:<br />
first {u&#8217;key&#8217;: 10} is passed in, then {u&#8217;foobar&#8217;: u&#8217;baz&#8217;, u&#8217;array&#8217;: [10, 20, 30], u&#8217;comp&#8217;: None} is passed in.</p>
<p>Was this change intentional? or was it a side-effect of switching from sre to re?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Viktor Ferenczi</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10131</link>
		<dc:creator>Viktor Ferenczi</dc:creator>
		<pubDate>Tue, 24 Apr 2007 22:01:07 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10131</guid>
		<description>Here is a solution to compile extension modules on Windows without Visual Studio 2003:

http://python.cx.hu/python-cjson/#win32

If anybody knows how to install simplejson with speedups (simplejson-1.7.1-py2.5.egg does not contains _speedups.c itself), please drop me a mail. This helps to make simplejson faster in my throughput comparision.

Viktor</description>
		<content:encoded><![CDATA[<p>Here is a solution to compile extension modules on Windows without Visual Studio 2003:</p>
<p><a href="http://python.cx.hu/python-cjson/#win32" rel="nofollow">http://python.cx.hu/python-cjson/#win32</a></p>
<p>If anybody knows how to install simplejson with speedups (simplejson-1.7.1-py2.5.egg does not contains _speedups.c itself), please drop me a mail. This helps to make simplejson faster in my throughput comparision.</p>
<p>Viktor</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alec</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10014</link>
		<dc:creator>Alec</dc:creator>
		<pubDate>Mon, 09 Apr 2007 18:24:35 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10014</guid>
		<description>Sorry about the patch-in-blog-comments. Of course I'll send this on by e-mail, along with tests and docs.</description>
		<content:encoded><![CDATA[<p>Sorry about the patch-in-blog-comments. Of course I&#8217;ll send this on by e-mail, along with tests and docs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bob</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10013</link>
		<dc:creator>bob</dc:creator>
		<pubDate>Mon, 09 Apr 2007 18:23:10 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10013</guid>
		<description>I have not accepted any hooks for SQL. However, the code in the above comment you were referring to is a generic proxy for SQL that encodes strings and has no hook at all into simplejson.

simplejson has an object hook on decode, which is not specifically there for JSON-RPC. It's there for completeness: you can encode custom objects, you should be able to get them back out as they came in with the appropriate code (generic object serialization).

I might consider accepting that patch if you add sufficient tests and documentation for it, and you send it by email or something. Blog comments are no good for preserving whitespace.</description>
		<content:encoded><![CDATA[<p>I have not accepted any hooks for SQL. However, the code in the above comment you were referring to is a generic proxy for SQL that encodes strings and has no hook at all into simplejson.</p>
<p>simplejson has an object hook on decode, which is not specifically there for JSON-RPC. It&#8217;s there for completeness: you can encode custom objects, you should be able to get them back out as they came in with the appropriate code (generic object serialization).</p>
<p>I might consider accepting that patch if you add sufficient tests and documentation for it, and you send it by email or something. Blog comments are no good for preserving whitespace.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alec</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10012</link>
		<dc:creator>Alec</dc:creator>
		<pubDate>Mon, 09 Apr 2007 17:56:15 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10012</guid>
		<description>I'm not dealing with SQL at all. I'm dealing with a lot of code that deals with a lot of UTF8, and encoding and decoding json all over the place. It's a lot more efficient for me to to pass around a handle to the root of a simplejson-produced object than to go back and re-encode my entire structure.

I totally understand that you don't want to embed custom string encoding into simplejson - these are details that should be handled by the consumer. But, I'm confused as to why you've accepted certain hooks for JSON-RPC and SQL but are not interested in more general hooks for string encoding. 

Here's my suggested patch for decoder.py. This does NOT change existing functionality and only tweaks the hooks to be consistent across all the object types, allowing me to write my own JSONDecoder class. I've tried to be as consistent as possible with the existing patterns. I'd like to rename "_scanner" to "scanner" but I'll leave that up to you.

&lt;code&gt;
--- dist/simplejson-1.7.1/simplejson/decoder.py	2007-03-17 23:05:43.000000000 -0700
+++ pyroot/simplejson-1.7.1-py2.4-macosx-10.4-i386.egg/simplejson/decoder.py	2007-04-09 10:47:30.000000000 -0700
@@ -125,11 +125,13 @@
         return pairs, end + 1
     if nextchar != '"':
         raise ValueError(errmsg("Expecting property name", s, end))
-    end += 1
     encoding = getattr(context, 'encoding', None)
-    iterscan = JSONScanner.iterscan
+    iterscan = getattr(context, '_scanner', JSONScanner).iterscan
     while True:
-        key, end = scanstring(s, end, encoding)
+        try:
+            key, end = iterscan(s, idx=end, context=context).next() # scanstring(s, end, encoding)
+        except StopIteration:
+            raise ValueError(errmsg("Expecting key", s, end))
         end = _w(s, end).end()
         if s[end:end + 1] != ':':
             raise ValueError(errmsg("Expecting : delimiter", s, end))
@@ -165,7 +167,7 @@
     nextchar = s[end:end + 1]
     if nextchar == ']':
         return values, end + 1
-    iterscan = JSONScanner.iterscan
+    iterscan = getattr(context, '_scanner', JSONScanner).iterscan
     while True:
         try:
             value, end = iterscan(s, idx=end, context=context).next()
&lt;/code&gt;</description>
		<content:encoded><![CDATA[<p>I&#8217;m not dealing with SQL at all. I&#8217;m dealing with a lot of code that deals with a lot of UTF8, and encoding and decoding json all over the place. It&#8217;s a lot more efficient for me to to pass around a handle to the root of a simplejson-produced object than to go back and re-encode my entire structure.</p>
<p>I totally understand that you don&#8217;t want to embed custom string encoding into simplejson - these are details that should be handled by the consumer. But, I&#8217;m confused as to why you&#8217;ve accepted certain hooks for JSON-RPC and SQL but are not interested in more general hooks for string encoding. </p>
<p>Here&#8217;s my suggested patch for decoder.py. This does NOT change existing functionality and only tweaks the hooks to be consistent across all the object types, allowing me to write my own JSONDecoder class. I&#8217;ve tried to be as consistent as possible with the existing patterns. I&#8217;d like to rename &#8220;_scanner&#8221; to &#8220;scanner&#8221; but I&#8217;ll leave that up to you.</p>
<p><code><br />
--- dist/simplejson-1.7.1/simplejson/decoder.py	2007-03-17 23:05:43.000000000 -0700<br />
+++ pyroot/simplejson-1.7.1-py2.4-macosx-10.4-i386.egg/simplejson/decoder.py	2007-04-09 10:47:30.000000000 -0700<br />
@@ -125,11 +125,13 @@<br />
         return pairs, end + 1<br />
     if nextchar != '"':<br />
         raise ValueError(errmsg("Expecting property name", s, end))<br />
-    end += 1<br />
     encoding = getattr(context, 'encoding', None)<br />
-    iterscan = JSONScanner.iterscan<br />
+    iterscan = getattr(context, '_scanner', JSONScanner).iterscan<br />
     while True:<br />
-        key, end = scanstring(s, end, encoding)<br />
+        try:<br />
+            key, end = iterscan(s, idx=end, context=context).next() # scanstring(s, end, encoding)<br />
+        except StopIteration:<br />
+            raise ValueError(errmsg("Expecting key", s, end))<br />
         end = _w(s, end).end()<br />
         if s[end:end + 1] != &#8216;:&#8217;:<br />
             raise ValueError(errmsg(&#8221;Expecting : delimiter&#8221;, s, end))<br />
@@ -165,7 +167,7 @@<br />
     nextchar = s[end:end + 1]<br />
     if nextchar == &#8216;]&#8217;:<br />
         return values, end + 1<br />
-    iterscan = JSONScanner.iterscan<br />
+    iterscan = getattr(context, &#8216;_scanner&#8217;, JSONScanner).iterscan<br />
     while True:<br />
         try:<br />
             value, end = iterscan(s, idx=end, context=context).next()<br />
</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bob</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10011</link>
		<dc:creator>bob</dc:creator>
		<pubDate>Mon, 09 Apr 2007 17:35:02 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10011</guid>
		<description>Embedded arrays don't happen in SQL. If they do, you're probably using PostgreSQL, and if you're using PostgreSQL then you should be able to do unicode stuff just fine.

I'm not particularly interested in taking any patches related to string re-encoding. It's not a bug that simplejson has consistent handling of strings.</description>
		<content:encoded><![CDATA[<p>Embedded arrays don&#8217;t happen in SQL. If they do, you&#8217;re probably using PostgreSQL, and if you&#8217;re using PostgreSQL then you should be able to do unicode stuff just fine.</p>
<p>I&#8217;m not particularly interested in taking any patches related to string re-encoding. It&#8217;s not a bug that simplejson has consistent handling of strings.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alec</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10010</link>
		<dc:creator>Alec</dc:creator>
		<pubDate>Mon, 09 Apr 2007 17:17:27 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-10010</guid>
		<description>Hey bob - 
The problem with your example is that it doesn't support embedded arrays of strings - i.e.
{"xyz": ["abc", "def"]}

But I did some experimentation with the existing hooks that you've provided in simplejson and it's ALMOST possible to in-place encoding of strings without monkeypatching simplejson. It would actually be possible to write a JSONDecoder class that did the string conversion for those of us that need/want it.

The only problem is in decoder.py, you're using a global JSONScanner that could be passed around in the 'context' - you're already providing a _scanner member of JSONDecoder

Here's the code I'd like to use:


def MWString(match, context):
    """
    Wrapper around JSONString that optionally re-encodes the string
    """
    result = simplejson.JSONString(match,context)
    result_encoding = context.result_encoding
    if result_encoding is None:
        return result
    
    return result.encode(result_encoding), end

# now locally monkey-patch the list of type handlers
MW_ANYTHING = copy(simplejson.ANYTHING)
MW_ANYTHING.remove(simplejson.JSONString)
MW_ANYTHING.append(simplejson.MWString)

class MWDecoder(simplejson.JSONDecoder):

    # this almost does it...
    _scanner = simplejson.Scanner(MW_ANYTHING)
    
    def __init__(self, encoding=None, object_hook=None, result_encoding=None, *args, **kwds):
        super(MWDecoder, self).__init__(encoding, object_hook, *args, **kwds)
        
        self.result_encoding = result_encoding


The only problem here is that self._scanner is lost because JSONObject and JSONArray reference simplejson.JSONScanner directly rather than getting it from the context. I'm happy to provide a patch to simplejson, but it's basically just:


-    iterscan = JSONScanner.iterscan
+    iterscan = getattr(context, '_scanner', JSONScanner).iterscan


in those two places.</description>
		<content:encoded><![CDATA[<p>Hey bob -<br />
The problem with your example is that it doesn&#8217;t support embedded arrays of strings - i.e.<br />
{&#8221;xyz&#8221;: ["abc", "def"]}</p>
<p>But I did some experimentation with the existing hooks that you&#8217;ve provided in simplejson and it&#8217;s ALMOST possible to in-place encoding of strings without monkeypatching simplejson. It would actually be possible to write a JSONDecoder class that did the string conversion for those of us that need/want it.</p>
<p>The only problem is in decoder.py, you&#8217;re using a global JSONScanner that could be passed around in the &#8216;context&#8217; - you&#8217;re already providing a _scanner member of JSONDecoder</p>
<p>Here&#8217;s the code I&#8217;d like to use:</p>
<p>def MWString(match, context):<br />
    &#8220;&#8221;"<br />
    Wrapper around JSONString that optionally re-encodes the string<br />
    &#8220;&#8221;"<br />
    result = simplejson.JSONString(match,context)<br />
    result_encoding = context.result_encoding<br />
    if result_encoding is None:<br />
        return result</p>
<p>    return result.encode(result_encoding), end</p>
<p># now locally monkey-patch the list of type handlers<br />
MW_ANYTHING = copy(simplejson.ANYTHING)<br />
MW_ANYTHING.remove(simplejson.JSONString)<br />
MW_ANYTHING.append(simplejson.MWString)</p>
<p>class MWDecoder(simplejson.JSONDecoder):</p>
<p>    # this almost does it&#8230;<br />
    _scanner = simplejson.Scanner(MW_ANYTHING)</p>
<p>    def __init__(self, encoding=None, object_hook=None, result_encoding=None, *args, **kwds):<br />
        super(MWDecoder, self).__init__(encoding, object_hook, *args, **kwds)</p>
<p>        self.result_encoding = result_encoding</p>
<p>The only problem here is that self._scanner is lost because JSONObject and JSONArray reference simplejson.JSONScanner directly rather than getting it from the context. I&#8217;m happy to provide a patch to simplejson, but it&#8217;s basically just:</p>
<p>-    iterscan = JSONScanner.iterscan<br />
+    iterscan = getattr(context, &#8216;_scanner&#8217;, JSONScanner).iterscan</p>
<p>in those two places.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bob</title>
		<link>http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-8535</link>
		<dc:creator>bob</dc:creator>
		<pubDate>Tue, 20 Mar 2007 03:58:13 +0000</pubDate>
		<guid isPermaLink="false">http://bob.pythonmac.org/archives/2007/03/18/simplejson-17/#comment-8535</guid>
		<description>No. Strings are text and unicode is the only suitable type for text in Python. The only correct solution is to fix your I/O boundaries. Here's an (untested) proxy for a DB-API cursor that doesn't support unicode:

&lt;pre&gt;
def ensure_str_dict(d, encoding):
    rval = {}
    for k, v in d.iteritems():
        rval[ensure_str(k, encoding)] = ensure_str(v, encoding)
    return rval

def ensure_str(s, encoding):
    if isintance(s, unicode):
        return s.encode(encoding)
    return s

class CursorProxy(object):
    def __init__(self, cur, encoding='utf-8'):
        self._cur = cur
        self._encoding = encoding

    def __getattr__(self, attr):
        return getattr(self._cur, attr)

    def execute(cur, sql, args=[]):
        if isinstance(args, dict):
            args = ensure_str_dict(args, self._encoding)
        else:
            args = [ensure_str(arg, self._encoding) for arg in args]
        return self._cur.execute(sql, args)
&lt;/pre&gt;</description>
		<content:encoded><![CDATA[<p>No. Strings are text and unicode is the only suitable type for text in Python. The only correct solution is to fix your I/O boundaries. Here&#8217;s an (untested) proxy for a DB-API cursor that doesn&#8217;t support unicode:</p>
<pre>
def ensure_str_dict(d, encoding):
    rval = {}
    for k, v in d.iteritems():
        rval[ensure_str(k, encoding)] = ensure_str(v, encoding)
    return rval

def ensure_str(s, encoding):
    if isintance(s, unicode):
        return s.encode(encoding)
    return s

class CursorProxy(object):
    def __init__(self, cur, encoding=&#8217;utf-8&#8242;):
        self._cur = cur
        self._encoding = encoding

    def __getattr__(self, attr):
        return getattr(self._cur, attr)

    def execute(cur, sql, args=[]):
        if isinstance(args, dict):
            args = ensure_str_dict(args, self._encoding)
        else:
            args = [ensure_str(arg, self._encoding) for arg in args]
        return self._cur.execute(sql, args)
</pre>
]]></content:encoded>
	</item>
</channel>
</rss>
