Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #77541

Re: Storing instances using jsonpickle

Date 2014-09-04 12:07 +0100
From MRAB <python@mrabarnett.plus.com>
Subject Re: Storing instances using jsonpickle
References <c54f7a2f-cf2c-4ee9-ba8e-a309761c1c6a@googlegroups.com> <mailman.13748.1409777587.18130.python-list@python.org> <46e782a5-b087-4f95-aadb-26e233bf5419@googlegroups.com> <5407A69B.3030707@mrabarnett.plus.com> <CAPTjJmob5Qntc_E_nXMBQB-wyccNy4_LuPo0bNKBSh2FsUv0=w@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.13764.1409828837.18130.python-list@python.org> (permalink)

Show all headers | View raw


On 2014-09-04 06:17, Chris Angelico wrote:> On Thu, Sep 4, 2014 at 9:39
AM, MRAB <python@mrabarnett.plus.com> wrote:
 >> I occasionally think about a superset of JSON, called, say, "pyson"
 >> ... ah, name already taken! :-(
 >
 > While I'm somewhat sympathetic to the concept, there are some parts
 > of your description that I disagree with. Am I misreading something?
 > Are there typos in the description and I'm making something out of
 > nothing?
 >
 >> It would add tuples, delimited by (...), which are not used
 >> otherwise (no expressions):
 >>
 >>     () => ()
 >>     (0, ) => (0)
 >
I'm thinking now that it might be better to have 'tuple()' and
'tuple(0)'.

 > This seems odd. Part of JSON's convenience is that it's a subset of
 > JavaScript syntax, so you can just plop a block of JSON into a REPL
 > and it'll decode correctly. With PyON (or whatever you call it), it'd
 > be nice to have the same correspondence; for a start, I would
 > strongly> encourage the "trailing comma is permitted" rule (so
 > [1,2,3,] is equivalent to [1,2,3]), and then I'd have the default
 > encoding for a single-element tuple include that trailing comma. If
 > (0) is a one-element tuple, you end up with a subtle difference
 > between a PyON decode and the Python interpreter, which is likely to
 > cause problems. It might even be worth actually mandating (not just
 > encouraging) that one-element tuples have the trailing comma, just to
 > prevent that.
 >
In that case, if you wanted to encode a (0, ), it would have to be
'tuple([0])', whereas 1+2j would have to be 'complex(i, 2)'. The
encoder would need to return [[0]] for the first case and [1, 2] for
the second.

 >> The key of a dict could also be int, float, or tuple.
 >
 > Yes! Yes! DEFINITELY do this!! Ahem. Calm down a little, it's not
 > that outlandish an idea...
 >
 >> It could support other classes, and could handle named arguments.
 >>
 >> For example, sets:
 >>
 >> To encode {0, 1, 2):
 >
 > Do you mean {0, 1, 2} here? I'm hoping you aren't advocating a syntax
 > that mismatches bracket types. That's only going to cause confusion.
 >
Yes, that's a typo.

 >>     Look in encoder dict for encoder function with class's name
 >> ('set') and call it, passing object.
 >>
 >>     Encoder returns positional and keyword arguments: [0, 1, 2] and
 >>     {}.
 >>
 >>     Output name, followed by encoded arguments in parentheses.
 >>
 >>     Encoder for set:
 >>
 >>     def encode_set(obj):
 >>         return list(obj), {}
 >>
 >> To decode 'set(0, 1, 2)':
 >>
 >>     Parse name: 'set'.
 >>
 >>     Parse contents of parentheses: [0, 1, 2] and {}.
 >>
 >>     Look in decoder dict for decoder function with given name
 >> ('set') and call it, passing arguments.
 >>
 >>     Result would be {0, 1, 2}.
 >>
 >>     Decoder for set:
 >>
 >>     def decode_set(*args):
 >>         return set(args)
 >>
 >> pyson.dumps({0, 1, 2}, decoders={'set': decode_set}) would return
 >> 'set(0, 1, 2)'.
 >>
 >> pyson.loads('set(0, 1, 2)', encoders={'set': encode_set}) would
 >> return {0, 1, 2}.
 >
 > This seems very much overengineered. Keep it much more simple; adding
 > set notation is well and good, but keyword arguments aren't necessary
 > there, and I'm not seeing a tremendous use-case for them.
 >
 > It's a pity Python has the collision of sets and dicts both using
 > braces. Pike went for two-character delimiters, which might be better
 > suited here; round brackets aren't used in JSON anywhere, so you can
 > afford to steal them:
 >
 > {'this':'is', 'a':'dict'}
 > ({'this','is','a','set'})
 >
 > Empty sets would be an issue, though, as they'll be different in
 > Python and this format. But everything else would work fine. You have
 > a two-character delimiter in PyON, and superfluous parentheses around
 > set notation in Python.
 >
 > (Sadly, this doesn't make it Pike-compatible, as Pike uses (<x,y,z>)
 > for sets. But it wouldn't have been anyway.)
 >
To encode {0, 1, 2}:

     Look in encoder dict for encoder function with class's name ('set')
     and call it, passing object.

     Encoder returns name and list of arguments: 'set' and [[0, 1, 2]].

     Output name, followed by encoded arguments in parentheses:
     'set([0, 1, 2])'.

     Encoder for set:

     def encode_set(obj):
         return 'set', [list(obj)]

To decode 'set([0, 1, 2])':

     Parse name: 'set'.

     Parse contents of parentheses as list: [[0, 1, 2]].

     Look in decoder dict for decoder function with given name ('set')
     and call it, passing arguments.

     Result would be {0, 1, 2}.

     Decoder for set:

     def decode_set(args):
         # Error-checking omitted.
         return set(args[0])

pyson.dumps({0, 1, 2}, decoders={'set': decode_set}) would return
'set([0, 1, 2])'.

pyson.loads('set([0, 1, 2])', encoders={'set': encode_set}) would
return {0, 1, 2}.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Storing instances using jsonpickle Josh English <Joshua.R.English@gmail.com> - 2014-09-03 13:32 -0700
  Re: Storing instances using jsonpickle Ned Batchelder <ned@nedbatchelder.com> - 2014-09-03 16:52 -0400
    Re: Storing instances using jsonpickle Josh English <Joshua.R.English@gmail.com> - 2014-09-03 15:30 -0700
      Re: Storing instances using jsonpickle MRAB <python@mrabarnett.plus.com> - 2014-09-04 00:39 +0100
        Re: Storing instances using jsonpickle Denis McMahon <denismfmcmahon@gmail.com> - 2014-09-04 01:11 +0000
      Re: Storing instances using jsonpickle Ned Batchelder <ned@nedbatchelder.com> - 2014-09-03 22:18 -0400
        Re: Storing instances using jsonpickle Sam Raker <sam.raker@gmail.com> - 2014-09-03 21:52 -0700
        Re: Storing instances using jsonpickle Josh English <Joshua.R.English@gmail.com> - 2014-09-15 12:30 -0700
      Re: Storing instances using jsonpickle Chris Angelico <rosuav@gmail.com> - 2014-09-04 15:17 +1000
        Re: Storing instances using jsonpickle Dan Sommers <dan@tombstonezero.net> - 2014-09-05 04:38 +0000
          Re: Storing instances using jsonpickle Chris Angelico <rosuav@gmail.com> - 2014-09-05 15:08 +1000
      Re: Storing instances using jsonpickle MRAB <python@mrabarnett.plus.com> - 2014-09-04 12:07 +0100
      Re: Storing instances using jsonpickle MRAB <python@mrabarnett.plus.com> - 2014-09-05 18:04 +0100
        Re: Storing instances using jsonpickle Marko Rauhamaa <marko@pacujo.net> - 2014-09-05 20:16 +0300
          Re: Storing instances using jsonpickle Ned Batchelder <ned@nedbatchelder.com> - 2014-09-05 13:30 -0400
            Re: Storing instances using jsonpickle Marko Rauhamaa <marko@pacujo.net> - 2014-09-05 21:04 +0300
              Re: Storing instances using jsonpickle Ned Batchelder <ned@nedbatchelder.com> - 2014-09-05 16:50 -0400
                Re: Storing instances using jsonpickle Marko Rauhamaa <marko@pacujo.net> - 2014-09-05 23:57 +0300
          Re: Storing instances using jsonpickle Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2014-09-06 00:18 +0200
      Re: Storing instances using jsonpickle Chris Angelico <rosuav@gmail.com> - 2014-09-06 10:20 +1000
      Re: Storing instances using jsonpickle MRAB <python@mrabarnett.plus.com> - 2014-09-06 17:32 +0100
      Re: Storing instances using jsonpickle Ned Batchelder <ned@nedbatchelder.com> - 2014-09-06 12:56 -0400
      Re: Storing instances using jsonpickle Terry Reedy <tjreedy@udel.edu> - 2014-09-06 14:27 -0400

csiph-web