Hi Steve, Steve Howe wrote:
How compatible are the findall() and xpath() methods ? findall() don't seem to handle more complicated XPath expressions. Why there is a difference between what they can handle ?
I would expect findall() to be the same as xpath(), but searching from the context node and always returning a list of items, making it compatible with ET's.
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. 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. Stefan