[XML-SIG] DOM API

[Greg Stein]

Paul Prescod wrote:
> 
> Fredrik Lundh wrote:
> >
> > the downside with Paul's line of reasoning is that it makes it
> > impossible to come up with something that is light-weight
> > also from the CPU's perspective...  not good.
> 
> That isn't true. I tend to think that usability is more important than
> performance but if we decide to optimize for performance then we can make
> a DOM-compatible API that is as fast as "qp". I mean the only thing that
> is harder to implement in the miniDOM is siblings -- where I chose
> convenience over efficiency. We can make the opposite choice.

I maintain that qp_xml is both highly performant and highly usable.

Per my other emails, I do not believe that the DOM is highly usable. I
also tend to believe that being slaved to the DOM API will always hamper
your performance when you *access* the data structure. Sure... you might
be able to build it nearly as fast (nearly! you may have more objects to
create), but you are constraining access to be through methods rather
than Python data structures.

> In fact, I think that the namespace and language support in qp already
> makes it relatively "heavyweight".

Those are necessary to retain all information from the input XML. Toss
those and you *really* toss out information.

IMO, they do not introduce any "heaviness". They are two attributes that
you can totally ignore. If your document is unconcerned with namespaces,
then ignore the .ns attribute. If you don't care about language-specific
handling in your app, then ignore the .lang attribute. *Nothing* forces
you to use those attributes, so that means they do *not* impinge upon
your client. The only thing their presence does is to add some
descriptive text in the API specification and introduce some overhead in
the parsing process.

> > I want something really light-weight, and highly pythonish, and I
> > don't care the slightest about TLA compatibility.

Go Fredrik! :-)  My kinda guy :-)

> It isn't a question of TLA compatibility. It's about using the data models
> used everywhere else in the world. Python conforms to posix conventions

Hello!?!?! Fredrik just said he DOES NOT CARE.

Why are you stating that he SHOULD? He gets to program according to
whatever guidelines *he* wants.

> To me, this is the central issue: to me, the Guido's genious lies in the
> fact that he usually chooses adapt something before re-inventing it. This
> makes learning Python easy. "Oh yeah, I recognize that from the other
> languages I use." Well, SAX and DOM are what the other languages use.

As I've said before, "Goody for them." You cannot be a slave to a single
API when it does not fulfill your needs. If I may speak for Fredrik, the
two of us want a Pythonish and *fast* way to parse XML, and we don't
care what other languages do because our application is in *PYTHON*. The
DOM does not satisfy our requirements.

> Anyhow, "qp" is hardly more "Pythonic" than in the lightweight DOM API.
> The following_cdata stuff is not like any API I've ever seen in Python or
> elsewhere. The call for "pythonic-ness" is mostly a strawman. The DOM
> works better in Python than in almost any other language: Nodelists are
> lists, NamedNodeLists are maps, object types are instance classes, lists
> can be heterogenous, etc.

The qp stuff uses native Python lists, mappings, and strings. The DOM
uses NodeLists, NamedNodeLists, and TextElements.

following_cdata is a design choice to model the underlying XML. My
implementation of it as a string attribute on an object is very
Pythonish. You just happen to disagree with my design choice. I don't
feel that the choice is not-Python, but is actually an interesting and
unique way to model the XML.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/