[Web-SIG] JSON object names (was Re: Time a for JSON parser in the standard library?)

Bob Ippolito bob at redivi.com
Mon Mar 17 15:58:31 CET 2008


On Mon, Mar 17, 2008 at 7:51 AM, Matt Goodall <matt at pollenation.net> wrote:
> Hi,
>
>  One thing I keep meaning to mention, prompted by the possibility of
>  simplejson being sucked into the std lib, is the handling of JSON object
>  names.
>
>    "An object structure is represented as a pair of curly brackets
>    surrounding zero or more name/value pairs (or members).  ***A name is
>    a string.***  A single colon comes after each name, separating the
>    name from the value." (My emphasis added.)
>
>  I noticed simplejson (and others, I suspect) allow more types than just
>  a string to be given as a name, although they're always deserialised to
>  unicode instances:
>
>   >>> loads(dumps({'s': None}))
>   {u's': None}
>   >>> loads(dumps({1: None}))
>   {u'1': None}
>   >>> loads(dumps({None: None}))
>   {u'null': None}
>   >>> loads(dumps({True: None}))
>   {u'True': None}
>   >>>
>
>  Am I reading the spec correctly? If so, is it worth explicitly
>  disallowing anything other than a string when serializing dict keys
>  before anything gets added to the std lib?
>
>
>  I guess the realy question is, has this been a problem to those who use
>  JSON a lot to make it worth changing?

I chose to make simplejson behave the way it does because it mirrored
what happens in JavaScript, and it was practical to do so. It's often
useful to (at least) have a number->object mapping without having to
do dict((str(k), v) for k,v in d.iteritems()). Having it do this for
True, False, and None makes somewhat less sense but I haven't had
anyone complain.

-bob


More information about the Web-SIG mailing list