Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Thu, 04 Sep 2014 12:07:14 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: python-list@python.org
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>
In-Reply-To: <CAPTjJmob5Qntc_E_nXMBQB-wyccNy4_LuPo0bNKBSh2FsUv0=w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.13764.1409828837.18130.python-list@python.org>
Lines: 145
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:77541

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}.