substantially less readable than ones with field names, = but they are indeed easy to = parse.

Personally, I rarely edit = these things manually except for the text fields, which are not = difficult to find. The fact that they=92re easy to parse is handy for = automation.

The pcb format is quite a bit more elaborate and the = savings from not rolling your own parser are more = significant.

I think you're criteria for what should go in libgeda are = spot-on btw. Nor do I have any problem with a C interface calling = python or gschem or for that matter C++. I do think providing a = clean C interface to libgeda gets by far the best return on investment, = since it's so widely known and with a little care wrappers can then be = provided almost automatically for a wide variety of languages (via SWIG = or some other similar mechanism -- or maybe Xorn facilitates this, I'm a = little unclear).

I don=92t find = deconstructing C data structures particularly easier than parsing the = format above. Just another layer I have to penetrate to get to the data. = I do significant processing with simple things like sed, which don=92t = handle binary data.

Wrappers CAN be provided, = but will they? FFI programming is not the easiest thing. I hear = complaints about the need for developers to maintain code. It = seems to me that one way to address these concerns is to avoid and = eliminate unnecessary = code.

Good question. = It's a great result if you get it but a lot more work than using a = serialization library, which is why the latter approach seems to me like = a useful step in the right = direction.
Serialization library? = Why do you want a extra, unnecessary, opaque interface? What, exactly, = are you trying to = accomplish?

Two = things:

1. A = human- and partial-parser-script-readable = format

We = have that, I think. But you left out the most important virtue: = *simple*.

I agree = that it's readable enough, though it could be better. I also agree = that simplicity is good.

2. = Full parsers for as many languages as possible without writing them by = hand

So instead, you = need to write an interface between a complicated parser and every = application by hand. Where=92s the = gain?

Here's what YAML = looks like from perl:

use = YAML::XS;

my $yaml =3D = Dump [ 1..4 ];
my $array =3D Load = $yaml;

But you left = out the next step: you have to deconstruct whatever it built to do = anything with it. To do that, you have to understand the construction. = While if I simply read the file (the format is too trivial for a reader = to deserve the name =93parser"), I go directly to *my* application=92s = model of the underlying data, on a trajectory that matches what I need. = Your example seems to build some sort of complex data structure. What if = a line by line data-driven approach is more = natural?