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 1 Mar 2010 11:08 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. > Come back when you actually have MANY users other than yourself using > this is real-world projects. Until then, it is too early to even consider > adding it the std library. Python comes with batteries included, but not > experimental batteries that aren't even built yet, let alone proven that > they work. I know that it is too early to be included in the library. But there is a chicken-and-egg problem. PEP 1 says you should circulate a design for discussion before writing code... I fully expect this sort of negative feedback, fully expect that it will be years (if ever) before the code makes it into the standard library, and yet I offer the design for your perusal, just on the slim chance that I might get a few constructive criticisms on the actual design to go along with all the silly strawmen reductio ad absurdum arguments by people who aren't even going to bother to read the thing. Best regards, Pat
From: Patrick Maupin on 1 Mar 2010 11:27 On Mar 1, 12:39 am, John Nagle <na...(a)animats.com> wrote: > Patrick Maupin wrote: > > All: > > > Finding .ini configuration files too limiting, JSON and XML to hard to > > manually edit, and YAML too complex to parse quickly, I have started > > work on a new configuration file parser. > > You're not supposed to edit those formats manually. > > John Nagle Opinions on that will vary, and as the saying goes, "everybody is entitled to his own opinions, but not his own facts." I submit as fact that there are many initialization files in each of these formats, and I would be willing to place a wager that the majority of the people on this list have used a text editor to modify at least one file in this category at least once. IOW, in my opinion (and it is only an opinion, not a fact), you are actually helping to make the case that a better format is needed. Regards, Pat
From: Robert Kern on 1 Mar 2010 12:13 On 2010-03-01 10:08 , Patrick Maupin wrote: > On Feb 28, 9:18 pm, Steven D'Aprano >> Come back when you actually have MANY users other than yourself using >> this is real-world projects. Until then, it is too early to even consider >> adding it the std library. Python comes with batteries included, but not >> experimental batteries that aren't even built yet, let alone proven that >> they work. > > I know that it is too early to be included in the library. But there > is a chicken-and-egg problem. PEP 1 says you should circulate a > design for discussion before writing code... Ignore it. That comment really doesn't apply to this case. That's for things that only make sense in the language or standard library, like context managers. For libraries like this, Steven's summary is correct. It needs to have a useful life as a third party package for a few years before you should propose it for inclusion into the standard library. By all means, distribute a design document for comment before you implement things; it's a reasonable practice. But don't bother with a PEP yet. -- 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: Patrick Maupin on 1 Mar 2010 12:34 On Mar 1, 11:13 am, Robert Kern <robert.k...(a)gmail.com> wrote: > Ignore it. That comment really doesn't apply to this case. That's for things > that only make sense in the language or standard library, like context managers. > For libraries like this, Steven's summary is correct. It needs to have a useful > life as a third party package for a few years before you should propose it for > inclusion into the standard library. By all means, distribute a design document > for comment before you implement things; it's a reasonable practice. But don't > bother with a PEP yet. So, I went and re-read PEP 1, and in the fine print it directs me to PEP 2. Mea culpa -- I though I understood the PEP. Nonetheless, the fact that I created what I call a "PEP draft" seems to have had more read into it than I meant. I will bear this in mind when I start future projects. I have a couple of projects, and contribute to another, which in no way should wind up in the standard library. But I find the lack of a good, up-to-date, configuration reader in the library to be an issue, which is why I had the temerity to try to start a discussion on what a good standard configuration file reader should be. Yes, I would like to create something compelling enough to go into the standard library. No, I don't expect it to wind up there for a very long time, if ever. BUT, at the same time, following the PEP format is very valuable for my project. It forces me to think more deeply about the problem I am solving and it forces me to write down some documentation. Really, it's no more burdensome than any other similar useful template. Or, to put it another way, it is my goal (which I may or may not be smart enough to reach) to write a module that anybody would want to use; that is good enough to put into the standard library. Whether this happens or not, one useful tool to help the module down that path (and produce a better module for me and other users even if it never becomes part of the standard library) is to think about what it takes to get into the standard library. Part of this involves writing the PEP. Writing a PEP is a good exercise; the format itself helps me to focus on important issues. So I was writing the contents of the PEP anyway, just for me. The real question, then, is when to release the PEP (vs. the code). I've already got some coding done, but it is not yet good enough to share, and if there is anybody else out there grappling with the same issues at this time, I would prefer not to go into production with it until they have had a chance to look over the design and offer insights and criticisms. Best regards, Pat
From: Robert Kern on 1 Mar 2010 13:05
On 2010-03-01 11:34 , Patrick Maupin wrote: > On Mar 1, 11:13 am, Robert Kern<robert.k...(a)gmail.com> wrote: >> Ignore it. That comment really doesn't apply to this case. That's for things >> that only make sense in the language or standard library, like context managers. >> For libraries like this, Steven's summary is correct. It needs to have a useful >> life as a third party package for a few years before you should propose it for >> inclusion into the standard library. By all means, distribute a design document >> for comment before you implement things; it's a reasonable practice. But don't >> bother with a PEP yet. > > So, I went and re-read PEP 1, and in the fine print it directs me to > PEP 2. Mea culpa -- I though I understood the PEP. > > Nonetheless, the fact that I created what I call a "PEP draft" seems > to have had more read into it than I meant. I will bear this in mind > when I start future projects. I have a couple of projects, and > contribute to another, which in no way should wind up in the standard > library. But I find the lack of a good, up-to-date, configuration > reader in the library to be an issue, which is why I had the temerity > to try to start a discussion on what a good standard configuration > file reader should be. > > Yes, I would like to create something compelling enough to go into the > standard library. No, I don't expect it to wind up there for a very > long time, if ever. BUT, at the same time, following the PEP format > is very valuable for my project. It forces me to think more deeply > about the problem I am solving and it forces me to write down some > documentation. Really, it's no more burdensome than any other similar > useful template. Certainly. The PEP format is a useful one. I've used it myself for some numpy design documents. But can you see why people might get confused about your intentions when you call it a draft PEP and post it to python-dev? If you stop calling it a PEP and stop talking about putting it in the standard library, people will stop being distracted by those issues. -- 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 |