[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