On 28.06.06 16:42:00, Stefan Behnel wrote:
Hi Andreas,
Andreas Pakulat wrote:
before trying to code it I'd like to get opinions about the following.
I'd like to add a global xpath function to lxml, that takes an element (the context) and an xpath expression (as string) and returns a list of tuples. Where each tuple has
a) 3 parts, the attribute name, value and containing element b) 2 parts, the text and the element that has the text as text or tail c) 1 part, the element itself.
I'm not very comfortable with the idea of inferring the semantics of a tuple result from the number of its entries.
Hmm, right...
I'd like to have this for XPathEvaluator (so I can highlight attribute and text nodes in the tree) and I'm willing to try and implement it in lxml.
Hmmm, it feels like a rather specific requirement.
Right.
What you really want is to always receive a reference to the libxml2 node that carries the result of an XPath expression.
I think, yes.
The problem is that this does not match very well with the rest of the API, where attributes 'do not exist', for example. I mean, your real problem is that you must evaluate arbitrary (opaque) XPath expressions and do not know what the non-element result of them means: Did a string come from an attribute or from element text? Which element did it come from? So you are interested in meta-data about the XPath result, not the result itself.
Well, yes. I need to know "where" in the tree the result(s) of the xpath expression are. This is easy enough for elements as I can walk up the tree (or even better use their hash-value as key into a dictionary). However when I get strings back I'm out of options...
I do not think many applications have this requirement.
Possibly not. So then I'll do something better with my time :-) It's just that lxml looks like "the worst implementation wrt. to the application" in the list of PyXML, libxml2 and lxml and I would have liked to change that a bit... Andreas -- You will always have good luck in your personal affairs.