ET 1.3 has suffered from something of a scope creep (wrt. XPath and C14N), but the main reason for the delay is that I'm in the process of changing jobs. No exact ETA, in other words, but it's definitely moving in the right direction.
Would you welcome the use of the XPath expression parser from pdis (http://sourceforge.net/projects/pdis-xpath/), but with a generator-oriented engine ? I gave it a try with a prototype and liked it.
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.
I like the path improvements in ET 1.3 a lot. Any idea when it will move beyond alpha?
ET 1.3 has suffered from something of a scope creep (wrt. XPath and C14N), but the main reason for the delay is that I'm in the process of changing jobs. No exact ETA, in other words, but it's definitely moving in the right direction.
Would you welcome the use of the XPath expression parser from pdis (http://sourceforge.net/projects/pdis-xpath/), but with a generator-oriented engine ? I gave it a try with a prototype and liked it.
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.