From: Tim P. <ti...@po...> - 2004-09-20 17:25:51
|
Just a link to a comp.lang.python posting pointing out a few perceived problems with PyYaml, I already know about most of them and am addressing them as part of my rewrite... although I'm not sure how fast it will be or how long it's going to take me for that matter :). Just wondered if it was worth an 'official' voice replying on the list or should we just leave it alone as it's really only criticising PyYaml for lacking in things it wasn't built to address?=20 There is also a general "whats the point of yaml" sort of tack aswell but I don't think theres anything constructive to be found in addressing that. ps If I get chance I'll look at locking down the unicode and import eval http://mail.python.org/pipermail/python-list/2004-September/241537.html Tim=20 |
From: Paul M. <pf_...@ya...> - 2004-09-20 21:32:53
|
Tim Parkin <ti...@po...> writes: > There is also a general "whats the point of yaml" sort of tack aswell > but I don't think theres anything constructive to be found in addressing > that. [visiting from python-list] I agree that there's probably nothing much to be gained by spawning a huge thread on this, but I will restate my point from python-list here, in case it helps to have an "outsider's" view. When I came looking at YAML, I was looking for a "configuration file" format, better than XML (which is too verbose and unreadable for my purposes). I'm *still* not sure if YAML is intended to address that need, or if serialisation is its sole focus (where, by serialisation, I mean dump/restore, with human-editability of dumpfiles being a peripheral benefit at best), or somewhere in between. A simple summary, somewhere on the website, of "why you might find YAML useful" would help a lot. And if serialisation is the main focus, a followup of "why YAML might be better than your language's native serialisation format" would help as well. (The bullet list on the yaml.org front page give some points, but leave me feeling "OK, but why should I care?") Paul. -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams |
From: Brian I. <in...@tt...> - 2004-09-21 04:25:00
|
On 20/09/04 22:32 +0100, Paul Moore wrote: > Tim Parkin <ti...@po...> writes: > > > There is also a general "whats the point of yaml" sort of tack aswell > > but I don't think theres anything constructive to be found in addressing > > that. > > [visiting from python-list] I'll field this one :) > I agree that there's probably nothing much to be gained by spawning a > huge thread on this, but I will restate my point from python-list > here, in case it helps to have an "outsider's" view. > > When I came looking at YAML, I was looking for a "configuration file" > format, better than XML (which is too verbose and unreadable for my > purposes). I'm *still* not sure if YAML is intended to address that > need, or if serialisation is its sole focus (where, by serialisation, > I mean dump/restore, with human-editability of dumpfiles being a > peripheral benefit at best), or somewhere in between. The spirit of YAML really comes down to finding a human pleasing format that also has a rock solid data model for viewing and sharing data within and across application boundaries and also programming language boundaries. Serialization is the main intent, yes, but serialization covers a very broad spectrum of what you can do with data. Dumping a data structure for debugging purposes is still serialization. YAML excels at this particular use case. The YAML folks realized that there was a very close relationship between the data models of programming languages like Perl Python and Ruby. And nobody was really taking advantage of that fact. We also realized that when people make up adhoc ways of describing data in text, they often come up with something close to YAML. Look at MIME headers or Debian package files. They are very YAMLesque. So we decided there was a sweet spot, and we could take advantage of that. It also turns out that a lot of people "relate" to YAML. They grok it right away. It makes sense to them. So that's what YAML is all about. YAML also seems at first sight to be a good format for config files. I think this really depends on a lot of factors. I personally think it's not an optimal choice in many instances. Apache's config file is awful in YAML. Well not as bad as it would be in XML, but definitely not as optimized for the task as the Apache format is. Then again, the Apache format probably wouldn't work well for, say, procmail. So it depends. If you want a quick, relatively decent format, YAML might work. Or you might be better off just rolling your own. Hope that helps. Cheers, Brian > A simple summary, somewhere on the website, of "why you might find > YAML useful" would help a lot. And if serialisation is the main focus, > a followup of "why YAML might be better than your language's native > serialisation format" would help as well. (The bullet list on the > yaml.org front page give some points, but leave me feeling "OK, but > why should I care?") > > Paul. > -- > The major difference between a thing that might go wrong and a thing > that cannot possibly go wrong is that when a thing that cannot > possibly go wrong goes wrong it usually turns out to be impossible to > get at or repair. -- Douglas Adams > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@be...> - 2004-09-21 05:21:30
|
On Tuesday 21 September 2004 07:27, Brian Ingerson wrote: > > When I came looking at YAML, I was looking for a "configuration > > file" format, better than XML (which is too verbose and unreadable > > for my purposes). I'm *still* not sure if YAML is intended to > > address that need, or if serialisation is its sole focus... > > So it depends. If you want a quick, relatively decent format, YAML > might work. Or you might be better off just rolling your own. We went to a lot of trouble to ensure that YAML is a pretty good match for the needs of people creating config files as well as for serialization; the inherent tension between the two sets of needs has been the driving force behind a lot of the design choices. I think the end result is a good match for both need sets. Granted, YAML may not be a perfect match for every pre-existing config file structure. For example, if someone went all-XML in a config file, YAML won't be a good match for the attributes/elements/mixed-content distinctions used. YAML is intended to be an excellent choice for someone creating a new config file format. If it turns out that in "common" such cases YAML is a "bad" match, then we have done something wrong when designing it. Similarly, YAML may not be a perfect match for every serialization need - obviously, platform specific formats are inherently a better match for data created within the specific platform (e.g., Java serialized objects). However, YAML is intended to be an excellent choice for cross-platform/human-readable serialization. Again, if it turns out that in "common" cases YAML is a "bad" match, we've done something wrong when designing it. If we did take the wrong path, we'd really like to hear about it (with a simple concrete example... examples do wonders). Have fun, Oren Ben-Kiki |