Draft PEP on RSON configuration file format
in [Python]
|
Prev: [ANNC] pynguin-0.1 (python-based turtle graphics application)
Next: Detecting new removable drives in Linux
From: Arnaud Delobelle on 2 Mar 2010 02:09 Erik Max Francis <max(a)alcyone.com> writes: > Patrick Maupin wrote: >> On Feb 28, 9:18 pm, Steven D'Aprano > Wait a minute... if JSON is too >> hard to edit, and RSON is a *superset* of >>> JSON, that means by definition every JSON file is also a valid RSON file. >>> Since JSON is too hard to manually edit, so is RSON. >> >> Well, Python is essentially a superset of JSON, with string escape >> handling being ever so slightly different, and using True instead of >> true, False instead of false, and None instead of null. YMMV, but I >> find it possible, even probable, to write Python that is far easier to >> edit than JSON, and in fact, I have used Python for configuration >> files that are only to be edited by programmers or other technical >> types. > > This not only seriously stretching the meaning of the term "superset" > (as Python is most definitely not even remotely a superset of JSON), > but still doesn't address the question. Is RSON and _actual_ superset > of JSON, or are you just misusing the term there, as well? If it is, > then your rationale for not using JSON makes no sense if you're making > a new format that's merely a superset of it. Obviously JSON can't be > that unreadable if you're _extending_ it to make your own "more > readable" format. If JSON is unreadable, so must be RSON. Your argument is utterly speculative as you are making clear you haven't read the OP's proposal. -- Arnaud
From: Daniel Fetchinson on 2 Mar 2010 05:09 >> > But you are working on a solution in search of a problem. The really >> > smart thing to do would be pick something more useful to work on. We >> > don't need another configuration language. I can't even say "yet >> > another" because there's already a "yet another" called yaml. >> >> And in case you are new here let me assure you that Paul is saying >> this with his full intention of being helpful to you. I also would >> think that working on such a project might be fun and educational for >> you but completely useless if you have users other than yourself in >> mind. Again, I'm trying to be helpful here, so you can focus on a >> project that is both fun/educational for you and also potentially >> useful for others. This RSON business is not one of them. > > OK, but I am a bit unclear on what you and/or Paul are claiming. It > could be one of a number of things. For example: > > - There is a preexisting file format suitable for my needs, so I > should not invent another one. I suspect this to be true, if we mean the same thing by "configuration file format". Especially if RSON will be a superset of JSON. > - If I invent a file format suitable for my needs, it couldn't > possibly be general enough for anybody else. Quite possibly, the reason is that the already existing file formats have an ecosystem around them that make them attractive. Your file format will have to cope with this barrier to attract new users which I think will be very difficult, given the wide range of already existing formats, covering just about any use case. > - Even if it was general enough for somebody else, there would only be > two of them. See above. > I've been known to waste time (or be accused of wasting time) on > various endeavors, but I like to know exactly *why* it is perceived to > be a waste. Don't get me wrong, I also waste lot of time on hobby/fun/educational projects ("waste" in this case is only meant as "useless for others", not "useless for me") because it's, well, hobby and fun and educational :) It's just good to know if a given project is in this category or outside. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
From: Robert Kern on 2 Mar 2010 11:34 On 2010-03-01 22:55 PM, Terry Reedy wrote: > On 3/1/2010 7:56 PM, Patrick Maupin wrote: >> On Mar 1, 5:57 pm, Erik Max Francis<m...(a)alcyone.com> wrote: >>> Patrick Maupin wrote: >>> This not only seriously stretching the meaning of the term "superset" >>> (as Python is most definitely not even remotely a superset of JSON), but >> >> Well, you are entitled to that opinion, but seriously, if I take valid >> JSON, replace unquoted true with True, unquoted false with False, >> replace unquoted null with None, and take the quoted strings and >> replace occurrences of \uXXXX with the appropriate unicode, then I do, >> in fact, have valid Python. But don't take my word for it -- try it >> out! > > To me this is so strained that I do not see why why you are arguing the > point. So what? The resulting Python 'program' will be equivalent, I > believe, to 'pass'. Ie, construct objects and then discard them with no > computation or output. Not if you eval() rather than exec(). It's reasonably well-accepted that JSON is very close to being a subset of Python's expression syntax with just a few modifications. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
From: Terry Reedy on 2 Mar 2010 12:59 On 3/2/2010 11:34 AM, Robert Kern wrote: > On 2010-03-01 22:55 PM, Terry Reedy wrote: >> On 3/1/2010 7:56 PM, Patrick Maupin wrote: >>> On Mar 1, 5:57 pm, Erik Max Francis<m...(a)alcyone.com> wrote: >>>> Patrick Maupin wrote: >>>> This not only seriously stretching the meaning of the term "superset" >>>> (as Python is most definitely not even remotely a superset of JSON), >>>> but >>> >>> Well, you are entitled to that opinion, but seriously, if I take valid >>> JSON, replace unquoted true with True, unquoted false with False, >>> replace unquoted null with None, and take the quoted strings and >>> replace occurrences of \uXXXX with the appropriate unicode, then I do, >>> in fact, have valid Python. But don't take my word for it -- try it >>> out! >> >> To me this is so strained that I do not see why why you are arguing the >> point. So what? The resulting Python 'program' will be equivalent, I >> believe, to 'pass'. Ie, construct objects and then discard them with no >> computation or output. > > Not if you eval() rather than exec(). >>> eval(1) creates and objects and discards it, with a net result of 'pass'. What do you think I am missing. It's reasonably well-accepted that > JSON is very close to being a subset of Python's expression syntax with > just a few modifications. It is specifically JavaScript Object Notation, which is very similar to a subset of Python's object notation (number and string literals and list and dict displays (but not set displays), and three named constants). Without operators, it barely qualifies, to me, even as 'expression syntax'. To me, comparing object notation with programming language is not helpful to the OP's purpose. His main claim is that JSON can be usefully extended but that YAML is too much, so that perhaps he, with help, can find a 'sweet spot' in between. Terry Jan Reedy
From: Robert Kern on 2 Mar 2010 13:39
On 2010-03-02 11:59 AM, Terry Reedy wrote: > On 3/2/2010 11:34 AM, Robert Kern wrote: >> On 2010-03-01 22:55 PM, Terry Reedy wrote: >>> On 3/1/2010 7:56 PM, Patrick Maupin wrote: >>>> On Mar 1, 5:57 pm, Erik Max Francis<m...(a)alcyone.com> wrote: >>>>> Patrick Maupin wrote: >>>>> This not only seriously stretching the meaning of the term "superset" >>>>> (as Python is most definitely not even remotely a superset of JSON), >>>>> but >>>> >>>> Well, you are entitled to that opinion, but seriously, if I take valid >>>> JSON, replace unquoted true with True, unquoted false with False, >>>> replace unquoted null with None, and take the quoted strings and >>>> replace occurrences of \uXXXX with the appropriate unicode, then I do, >>>> in fact, have valid Python. But don't take my word for it -- try it >>>> out! >>> >>> To me this is so strained that I do not see why why you are arguing the >>> point. So what? The resulting Python 'program' will be equivalent, I >>> believe, to 'pass'. Ie, construct objects and then discard them with no >>> computation or output. >> >> Not if you eval() rather than exec(). > > >>> eval(1) > > creates and objects and discards it, with a net result of 'pass'. > What do you think I am missing. x = eval('1') > It's reasonably well-accepted that >> JSON is very close to being a subset of Python's expression syntax with >> just a few modifications. > > It is specifically JavaScript Object Notation, which is very similar to > a subset of Python's object notation (number and string literals and > list and dict displays (but not set displays), and three named > constants). Without operators, it barely qualifies, to me, even as > 'expression syntax'. Literal expression syntax, then. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco |