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: Erik Max Francis on 2 Mar 2010 22:20 Patrick Maupin wrote: > 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." Huh? That's the argument being used against you, not the argument being ascribed to you. You're getting confused about something, somewhere. -- Erik Max Francis && max(a)alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis I wonder if heaven got a ghetto -- Tupac Shakur
From: Patrick Maupin on 2 Mar 2010 22:35 On Mar 2, 9:20 pm, Erik Max Francis <m...(a)alcyone.com> wrote: > Patrick Maupin wrote: > > 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." > > Huh? That's the argument being used against you, not the argument being > ascribed to you. You're getting confused about something, somewhere. > > -- > Erik Max Francis && m...(a)alcyone.com &&http://www.alcyone.com/max/ > San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis > I wonder if heaven got a ghetto > -- Tupac Shakur Yes, it is very confusing. Steven used that purported argument against me, and then since I disagreed with it, it apparently meant that I was arguing that changing the file extension type (which I've never even proposed or discussed, btw) from json to rson somehow magically makes a preexisting file all better. I have a headache now, and it will only get worse, so that's really all I have left to say about this issue. Best regards, Pat
From: Steven D'Aprano on 3 Mar 2010 00:00 On Tue, 02 Mar 2010 19:35:20 -0800, Patrick Maupin wrote: > Yes, it is very confusing. Steven used that purported argument against > me, and then since I disagreed with it, it apparently meant that I was > arguing that changing the file extension type (which I've never even > proposed or discussed, btw) from json to rson My argument is *figurative*, not literal. > somehow magically makes a preexisting file all better. You might not have intended that ludicrous conclusion, but it was implied by some of your posts, particularly the early ones. Of course I don't think that you *actually* believe the conclusion. I believe that, whatever the real or imagined benefit of RSON over JSON, in this thread you have attempted to over-sell RSON while giving relatively little justification for it. I wish you every success in your project, but think that it is off-topic for a Python discussion group. -- Steven
From: Erik Max Francis on 3 Mar 2010 00:36 Patrick Maupin wrote: > On Mar 2, 9:20 pm, Erik Max Francis <m...(a)alcyone.com> wrote: >> Patrick Maupin wrote: >>> 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." >> Huh? That's the argument being used against you, not the argument being >> ascribed to you. You're getting confused about something, somewhere. > > Yes, it is very confusing. Steven used that purported argument > against me, and then since I disagreed with it, it apparently meant > that I was arguing that changing the file extension type (which I've > never even proposed or discussed, btw) from json to rson somehow > magically makes a preexisting file all better. No, that was not the point he was making. You should reread more carefully (and be aware of sarcasm). -- Erik Max Francis && max(a)alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis Perfect situations must go wrong -- Florence, _Chess_
From: mk on 3 Mar 2010 10:46
Paul Rubin wrote: > Patrick Maupin <pmaupin(a)gmail.com> writes: >> One of my complaints. If you had read the document you would have >> seen others. I actually have several complaints about YAML, but I >> tried to write a cogent summary. > Yaml sucks, but seems to have gotten some traction regardless. > Therefore the Python principle of "there should be one and only one > obvious way to do it" says: don't try to replace the existing thing if > your new thing is only slightly better. With all due respect, Paul, and with thanks for all the help you've given me, I have to disagree here: this is a really, really complicated matter and I think there is a case even for making things slightly better. I think this is a matter of "investment period", so to speak: is it short or long? In short term, it absolutely makes no sense to produce even slight improvement. But in the long run it will almost certainly pay off to switch to smth even somewhat better implementation (say, imaginary "20%" if you get my drift): suppose we stay with sucky format for 10 years. Wouldn't it make sense to implement a new one and be "in red" in terms of effort expended versus saved for 3 years, but then be "in black" for the following 7 years? > Just deal with the existing > thing's imperfections or make improvements to it. OK, but how? How would you make up e.g. for JSON's lack of comments? Producing accompanying ".json-comment" format and writing libraries that parse the comments and interleave them with JSON file for producing human-readable commented output? I think the effort required by all parties, both developers and users, before they produced smth like this and learned to use this widely and comprehensively, for this manner of improvement would be so high that it would be actually cheaper to dump the thing and develop smth new that has built-in support for comments. If you mean some other method of improving existing things like formats, well let's hear it; but I for one don't see any worth doing to significant extent really, other than dumping the thing or producing next, improved version at least. Improvement: other than making basic tools like parsing libraries editors, what improvements can you realistically make? And such improvements in and of themselves are not very expensive: my GPL Notepad++ has syntax highlighting for YAML (on top of gazillion other languages), and there are parsing libraries for it. So where's this terrible cost to it? OTOH, if YAML produces net benefit for as few as, say, 200 people in real world, the effort to make it has been well worth it. > If you can make a > really powerful case that your new thing is 1000x better than the old > thing, that's different, but I don't think we're seeing that here. Perhaps in ideal world we would be able to develop smth good or at least decent without long series of abominations preceding it. But I don't think we live in such world and I don't think it's possible to produce a decent format (or language) without decades of having to deal with abominations first. We learn as we go along, there's no way but to produce whatever works best at the moment, learning from it, dumping it and then doing smth better. I don't think e.g. Python could be produced without C, COBOL and Fortran preceding it: it's important not only to know how to do it, but also how (and why) not to do it, and learning that can't be done without producing some sort of abomination. I'd argue that abominations are inevitable price of progress and evolution. > Also, XML is used for pretty much everything in the Java world. It > sucks too, but it is highly standardized, it observably gets the job > done, there are tons of structure editors for it, etc. Frankly > I'd rather have stayed with it than deal with Yaml. http://myarch.com/why-xml-is-bad-for-humans http://www.ibm.com/developerworks/xml/library/x-sbxml.html Such reasons alone are enough to consider dumping XML for smth better. Today I had to hand-edit XML config files for two programs (no other option). The files were rather large, complicated and doing it frankly sucked. I also have to maintain a few applications that internally use XML as data format: while they are tolerable, they still leave smth to be desired, as those applications are really slow for larger datasets, their users systematically make errors (like forgetting to attach DTD before editing), and working across various versions of Windows is still not perfect. If somebody out there invents smth that is better than XML "only" by half, I'm all for it. > There are too many of these damn formats. We should ban all but one of > them (I don't much care which one). And making even more of them is not > the answer. I think this is a situation of "beware of what you wish for". Suppose those alternative formats disappeared and you'd have no tools, however imperfect, to use them: I think that in many, many contexts deficiencies of "the" format would be so painful that most developers would just write their own "private" ones, and everyone would be even worse off than they are now. I wouldn't worry too much about "stretching scarce resources thin" either: abominations completely unfit to live waste little in the way of resources, and we learn a deal off them too. There are demonstrable benefits to this too: I for one am happy that ReST is available for me and I don't have to learn a behemoth such as DocBook to write documentation. (imaginary dialog: Paul: "eat your greens and learn your DocBook!" Me: "but I don't like it and there's too much of it..." ;-) OK me off the soapbox. Regards, mk |