Storing instances using jsonpickle

[Chris Angelico]

On Thu, Sep 4, 2014 at 9:39 AM, MRAB <python at 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)

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.

> 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.

>     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.)

ChrisA