Congratulations for ET 1.3. I used the ElementTree 1.3a3-20070912-preview XPath engine to request dynamically-created trees (see http://lauploix.blogspot.com/2008/07/xpath-for-my-trees.html); Do you think the way the XPath engine request data from the Element may change with time?
Clever! (I've exposed non-XML things via ET-compatible API:s before, but I haven't used XPath against them).
As for your specific question, the XPath engine is guaranteed to work on anything that implements the ET Element API (it's used for both ET and cET, and I think even lxml.etree supports using the ET engine for maximum compatibility, in addition to it's own, more extensive C-level implementation).
Question... I have a prototype of a (better than ET's but still incomplete) Xpath engine, based on some pdis (http://sourceforge.net/projects/pdis-xpath/) code. I especially appreciated the XPath expression parser. I re-wrote the Xpath findall equivalent in pdis so that it yields the elements instead of creating lists.
Is that something you may want to see in ET, or do you want to keep ET XPath engine simpler?
Just a question about the element tree API: do you feel it could evolve a bit in new versions? Here are a few suggestions (that would help me, yes, when making XPath requests on dynamically created elements, but which could be useful anyway):
* Requesting children that have a specific tag and/or a specific attributes with (optional) values. Today the XPath engine goes though all children, then pick the right ones. If the XPath engine used this function, that would allow it to be used in a situation where you have thousands of (virtual until instantiated) Elements, if the XPath request is properly written.
* Having a "parent" (python) attribute in each node, so that you don't need to have a map to go one level higher in the hierarchy.
So far I exposed _children, tag and attrib. I just hope I don't need more.
One suggestion: why not having a "parent" in each Element? Today you create a map of all parents the first time you need to evaluate the ".." XPath expression. I cannot use it for a tree that is too large.
Congratulations for ET 1.3. I used the ElementTree 1.3a3-20070912-preview XPath engine to request dynamically-created trees (see http://lauploix.blogspot.com/2008/07/xpath-for-my-trees.html); Do you think the way the XPath engine request data from the Element may change with time?
Clever! (I've exposed non-XML things via ET-compatible API:s before, but I haven't used XPath against them).
As for your specific question, the XPath engine is guaranteed to work on anything that implements the ET Element API (it's used for both ET and cET, and I think even lxml.etree supports using the ET engine for maximum compatibility, in addition to it's own, more extensive C-level implementation).
Question... I have a prototype of a (better than ET's but still incomplete) Xpath engine, based on some pdis (http://sourceforge.net/projects/pdis-xpath/) code. I especially appreciated the XPath expression parser. I re-wrote the Xpath findall equivalent in pdis so that it yields the elements instead of creating lists.
Is that something you may want to see in ET, or do you want to keep ET XPath engine simpler?
Just a question about the element tree API: do you feel it could evolve a bit in new versions? Here are a few suggestions (that would help me, yes, when making XPath requests on dynamically created elements, but which could be useful anyway):
* Requesting children that have a specific tag and/or a specific attributes with (optional) values. Today the XPath engine goes though all children, then pick the right ones. If the XPath engine used this function, that would allow it to be used in a situation where you have thousands of (virtual until instantiated) Elements, if the XPath request is properly written.
* Having a "parent" (python) attribute in each node, so that you don't need to have a map to go one level higher in the hierarchy.
So far I exposed _children, tag and attrib. I just hope I don't need more.
One suggestion: why not having a "parent" in each Element? Today you create a map of all parents the first time you need to evaluate the ".." XPath expression. I cannot use it for a tree that is too large.