Draft PEP on RSON configuration file format

[Steven D'Aprano]

On Tue, 02 Mar 2010 11:30:32 -0800, Patrick Maupin wrote:

> On Mar 2, 11:59 am, Terry Reedy <tjre... at 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