Hello Stefan, Friday, May 26, 2006, 5:00:08 AM, you wrote:
Well, it /is/ compatible with ET's. That is the main reason why it does not support full XPath expressions. Its expressions follow the documentation from the ElementTree library. Perhaps *too* compatible... :)
What would be the advantage of not being ET compatible here? Is there anything you can do with findall(), find() and findtext() that you couldn't do with xpath() if you wanted to? Note, BTW, that both are similarly fast for similar expressions. If you wanted more speed, you'd go for pre-parsed XPath expressions anyway.
IMHO, the only two reasons why these three functions are there are
1) they are ET compatible 2) they are simple
We had the discussion pop up a few times if implementing findall() through xpath() would be a good idea. It was generally agreed (and demonstrated in code) that this would too easily break ET compatibility, which was not considered worth it. Ok, reason is compatibility. Two points:
1) Shouldn't it be clearly documented ? 2) Since xpath() supports a superset of the expressions findall() does, isn't the compatibility ensured ? Or does findall() support anything xpath() does not ? It makes no sense to cripple etree´s findall() in order to to support only what ET's findall() does. -- Best regards, Steve mailto:howe@carcass.dhs.org