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: Philip Semanchuk on 1 Mar 2010 16:02 On Mar 1, 2010, at 3:08 PM, 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. Just deal with the existing > thing's imperfections or make improvements to 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. > > 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. > > 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 dunno, times change, needs change. We must invent new tools, be those computer languages or data formats. Otherwise we'd still be programming in COBOL and writing fixed-length records to 12 inch floppies.* If Mr. Maupin was a giant corporation trying to shove a proprietary format down our collective throats, I might object to RSON. But he's not. He appears willing for it live or die on its merits, so I say good luck to him. I don't want or need it, but someone else might. Cheers Philip * You had floppies? Bleddy luxury! We wrote our data on wood pulp we'd chewed ourselves and dried into paper, using drops of our own blood to represent 1s and 0s.
From: Patrick Maupin on 1 Mar 2010 16:11 On Mar 1, 2:42 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote: > Patrick Maupin <pmau...(a)gmail.com> writes: > > But for my use-case, YAML is irretrievably broken. Sure, it looks > > reasonably nice, but it increases regression runtime unacceptably. > > How big are the files that you want to parse with it? Sheesh. Tiny, but over and over. The rst2pdf testsuite can generate approximately 160 PDFs, totalling around 2.5 MB, in around 22 seconds on one of my machines. But if I replace the JSON parser with a YAML parser, that goes up to 55 seconds. Wait, maybe it's because JSON is optimized in C! Nope, using JSON but disabling the C scanner only takes it to 22.3 seconds... > > > Well, I've looked at the YAML parser and I can assure you that I will > > not be contributing to that project. > > So write a new one that parses the same syntax, but cleaner and faster. But there are already several parsers for YAML, and none of them agree! The syntax definition is a mess. The thing's been in development for 10 years now, and there is no one true way to do it. Seriously, YAML overreaches for what I want. > > XML can certainly be made readable by humans. It's hard to make it > > writeable by (average) humans just using a regular text editor, > > I do it all the time; it's a bit dreary but not difficult. And there is > absolutely no way to get anything done in this field anymore without > dealing with XML from time to time. So given that we all have some > experience using it, it's sensible to stick with it. But people "in this field" are not really my target audience. Well, I mean people in this field are the target audience for the library, but not for the writing of the actual text files. > ReST is another abomination that should never have gotten off the > ground. It is one of the reasons I react so negatively to your > config format proposal. It just sounds like more of the same. Well, that clarifies a lot. I guess we'll just have to agree to disagree :-) Regards, Pat
From: Emile van Sebille on 1 Mar 2010 17:12 On 3/1/2010 1:02 PM Philip Semanchuk said... > * You had floppies? Bleddy luxury! We wrote our data on wood pulp we'd > chewed ourselves and dried into paper, using drops of our own blood to > represent 1s and 0s. You had left-over blood?!! Emile :)
From: Erik Max Francis on 1 Mar 2010 18:30 Daniel Fetchinson wrote: >>> 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; >> 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. Agreed. Even YAML's acronym indicates that it is already a bridge too far; we don't need more. -- 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 It's better to be quotable than to be honest. -- Tom Stoppard
From: Erik Max Francis on 1 Mar 2010 18:33
Patrick Maupin wrote: > On Mar 1, 12:03 pm, Paul Rubin <no.em...(a)nospam.invalid> wrote: > >> 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. > > The only "in search of" here is that, instead of working on a point > solution for my particular problem, I am "in search of" a solution > that is a bit more elegant and general, and that might help solve > other people's problems too. If you are not one of those that has > this sort of problem at this point in time, then feel free to kill- > file this thread. Psst. That you're allowed to present the idea that you think is good doesn't mean that other people aren't allowed to respond and point out that in their opinion it's not such a good idea. You don't own this or any other thread. -- 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 It's better to be quotable than to be honest. -- Tom Stoppard |