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: Patrick Maupin on 2 Mar 2010 14:30 On Mar 2, 11:59 am, Terry Reedy <tjre...(a)udel.edu> wrote: > To me, comparing object notation with programming language is not > helpful to the OP's purpose. Yes, I agree, it was a distraction. I fell into the trap of responding to the ludicrous claim that "if X is a superset of Y, then X cannot possibly look better than Y" (a claim made by multiple people all thinking it was clever) by showing that Y has other supersets that do in fact look better than Y. In doing this, I made the mistake of choosing a superset of an analogue to Y, rather than to Y itself. When called out on it, I showed that, in fact, the actual X that IS a superset of Y can be used in a way that looks better. However, you are right that JSON is such a small subset of JS that it's really pretty ridiculous to even compare them, but that still makes the point that the original argument I was trying to refute is completely specious. In retrospect, though, I should have chosen a better way to make that point, because I let myself get caught up in making and then defending a flippant statement that I don't really care about one way or the other. > 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. An excellent summary of my position. Thanks, Pat
From: Steven D'Aprano on 2 Mar 2010 18:36 On Tue, 02 Mar 2010 11:30:32 -0800, Patrick Maupin wrote: > On Mar 2, 11:59 am, Terry Reedy <tjre...(a)udel.edu> wrote: > >> To me, comparing object notation with programming language is not >> helpful to the OP's purpose. > > Yes, I agree, it was a distraction. I fell into the trap of responding > to the ludicrous claim that "if X is a superset of Y, then X cannot > possibly look better than Y" (a claim made by multiple people all > thinking it was clever) by showing that Y has other supersets that do in > fact look better than Y. It's not ludicrous. You claim that: (1) JSON is too hard to edit; (2) RSON is a superset of JSON (the PEP even explicitly says "All valid UTF-8 encoded JSON files are also valid RSON files"); (3) which implies that all JSON files are valid RSON files. If you reject the logical conclusion that RSON must therefore also be too hard to edit, then perhaps JSON isn't too hard to edit either. You seem to be taking the position that if you start with a config file config.json, it is "too hard to edit", but then by renaming it to config.rson it magically becomes easier to edit. That *is* ludicrous. Perhaps what you mean to say is that JSON *can be* (not is) too hard to edit, and RSON *can be* too hard to edit too, but RSON has additional benefits, including being easier to edit *sometimes*. So far you have done (in my opinion) a really poor job of explaining what those benefits are. You've bad-mouthed existing config formats, then tried to convince us that RSON is almost exactly the same as one of those formats apart from a couple of trivial changes of spelling (True for true, etc.). In my opinion, if you're going to get any traction with RSON, you need to demonstrate some examples of where JSON actually is hard to write, and show how RSON makes it easier. It's not good enough showing badly written JSON, it has to be examples that can't be written less badly given the constraints of JSON. -- Steven
From: Paul Rubin on 2 Mar 2010 19:33 Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > (3) which implies that all JSON files are valid RSON files. > > If you reject the logical conclusion that RSON must therefore also be too > hard to edit, then perhaps JSON isn't too hard to edit either. I would say that JSON is hard to edit because, among other things, it has no comment syntax. It's quite difficult to maintain a hand-edited JSON file, or figure out what to edit into it, if it can't have any comments in it describing what it's doing. JSON is a serialization format for machine to machine communication, not intended for hand editing. Simply adding a comment syntax to JSON would go a long way towards making it easier to edit.
From: Patrick Maupin on 2 Mar 2010 21:26 On Mar 2, 5:36 pm, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > You seem to be taking the position that if you start with a config file > config.json, it is "too hard to edit", but then by renaming it to > config.rson it magically becomes easier to edit. That *is* ludicrous. No, but that seems to be the position you keep trying to ascribe to me: "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." > Perhaps what you mean to say is that JSON *can be* (not is) too hard to > edit, and RSON *can be* too hard to edit too, but RSON has additional > benefits, including being easier to edit *sometimes*. I have said as much, in multiple prior postings on this thread, if you care to look. > So far you have done (in my opinion) a really poor job of explaining what > those benefits are. That's certainly a valid complaint, and I can certainly believe that's true (and I'm going to be working on the doc some more), but instead of making this complaint, you made the (still silly IMO) assertion that a superset has to be as unreadable as the base set. > You've bad-mouthed existing config formats, then > tried to convince us that RSON is almost exactly the same as one of those formats apart from a couple of trivial changes of spelling (True for true, etc.). This is conflating two different issues. In a lame attempt to show the silliness of the argument that the superset must be as bad as the subset, I was trying to explain that, if you make a very few changes, Python is a superset of JSON. However, my lame attempt at this was obviously as poorly thought out as some of the rest of my words, because it started an additional discussion that wasn't really germane to the real issues about configuration files. > In my opinion, if you're going to get any traction with RSON, you need to > demonstrate some examples of where JSON actually is hard to write, and > show how RSON makes it easier. It's not good enough showing badly written > JSON, it has to be examples that can't be written less badly given the > constraints of JSON. Agreed, and I will be working on that. Best regards, Pat
From: Alf P. Steinbach on 2 Mar 2010 21:54
* Patrick Maupin: > On Mar 2, 5:36 pm, Steven D'Aprano <st...(a)REMOVE-THIS- > cybersource.com.au> wrote: >> You seem to be taking the position that if you start with a config file >> config.json, it is "too hard to edit", but then by renaming it to >> config.rson it magically becomes easier to edit. That *is* ludicrous. > > No, but that seems to be the position you keep trying to ascribe to > me: "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." Just a heads-up: IME it's next to impossible (maybe actually impossible) to convince Steven that your position is not the one he ascribes to you. At least not without an extremely lengthy debate veering off on multiple similar tangents plus some that one would never dream of. So I'd give up on that. Anyway, I agree with the sentiments expressed by many in this thread that what's important is the established "eco-culture", not the editability. Thus, even though XML isn't all that editable it's what I'd choose by default for rich configuration information, regardless of whether some simpler to edit alternative existed. Simply because there are so many XML tools out there, and people know about XML. It's like MS-DOS once became popular in spite of being extremely technically imperfect for its purpose, and then Windows... :-) Cheers, - Alf |