On Mon, Mar 17, 2008 at 7:51 AM, Matt Goodall <[EMAIL PROTECTED]> 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com