lxml/ElementTree and .tail
cemerick at snowtide.com
Thu Nov 16 12:50:10 CET 2006
Thanks for the comments and thoughts. I must admit that I have an
overwhelming feeling of having just stepped into the middle of a
complex, heated conversation without having heard the preamble.
(FYI, this reply is only an attempt to help those that come
afterwards -- I'm not looking to advocate much of anything here.)
Fredrik's invocation of the "infoset" term led me to a couple of
quick searches that clarified the state of play. Here he sets the
stage for the .tail behaviour that I originally posted about:
And it looks like there have been tussles over other mismatches in
expectations before, specifically around how namespaces are handled:
From what I can see, there are more than a few people that have
stumbled with ElementTree's API because of their preexisting
expectations, which others have probably correctly bucketed as
"implementation details". This comes as quite a shock to those who
have stumbled (including myself) who have, lo these many years, come
to view those details as the only standard that matters (perhaps
simply because those details have been so consistent in our experience).
Which, in my view, is just fine -- different strokes for different
folks, and all that. When I originally started poking around the
python xml world, I was somewhat confused as to why 4suite/Domlette
existed, as it seemed pretty clear that ElementTree had crystallized
a lot of mindshare, and has a very attractive API to boot.
Thankfully, I can now see its appeal, and am very glad it's around,
as it seems to have all of those comfortable implementation details
that I've been looking for. :-)
As for the infoset vs. "sequence of piggies" nut: if ElementTree's
infoset approach is technically correct, then wouldn't it also be
correct to use a .head attribute instead of a .tail attribute? Example:
might be represented as:
<Element a: head='', text='last'>
<Element b: head='first', text='middle'>
If I'm wrong, just chalk it up to the fact that this is the first
time I've ever looked at the Infoset spec, and I'm simply confused.
If that IS a technically-valid way to represent the above xml
fragment . . . then I guess I'll make sure to tread more carefully in
the future around tools that work in infoset terms. For me, it turns
out that sequences of piggies really are important, at least in
contexts where XML is merely a means to an end (either because of the
attractiveness of the toolsets or because we must cope with what
we're provided as input) and where consistency with existing tools
(like those that adhere to DOM level 2/3) and expectations are
critical. I think this is what Paul was nodding towards with his
original response to Stefan's response.
On Nov 16, 2006, at 5:11 AM, Fredrik Lundh wrote:
> Paul Boddie wrote:
>>> Yes, it is. Just look at the API. It's an attribute of an
>>> Element, isn't it?
>>> What other API do you know where removing an element from a data
>>> leaves part of the element behind?
>> I guess it depends on what you regard an element to be...
> Stefan said "Element", not "element".
> "Element" is a class in the "ElementTree" module, which can be used to
> *represent* an XML element in an XML infoset, including all the data
> *inside* the XML element, and any data *between* that XML element and
> the next one (which is always character data, of course).
> It's not very difficult, really; especially if you, as Stefan said,
> think in infoset terms rather "a sequence of little piggies" terms.
More information about the Python-list