On Thu, Sep 4, 2014 at 9:39 AM, MRAB <pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list