Re: [lxml] Possible bug with etree.XPath
An error will only manifest when actually evaluating the XPath:
...
Note that you won't run into the error when the XPath predicate's not applied i.e. contains() is not even called:
...
So calling with the wrong arg number is an XPath runtime, not an XPath compile time error.
Indeed you wouldn't know if there's an error or not at compile time:
That's what I was asking about: determining at compile time, if practical. We do our XPath lookups inside a browser, but we can read the scripts that provide the XPaths with a Python script. I understand if the lxml devs do not consider this a bug, but it would be helpful for us. I recognize your point about Python having the same behavior, except that the set of XPath 1.0 functions and their arguments are well-defined. -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001
Alex Vincent schrieb am 22.01.2015 um 07:39:
Holger Joukl schrieb:
So calling with the wrong arg number is an XPath runtime, not an XPath compile time error.
Indeed you wouldn't know if there's an error or not at compile time:
That's what I was asking about: determining at compile time, if practical. We do our XPath lookups inside a browser, but we can read the scripts that provide the XPaths with a Python script.
I understand if the lxml devs do not consider this a bug, but it would be helpful for us. I recognize your point about Python having the same behavior, except that the set of XPath 1.0 functions and their arguments are well-defined.
It's not about the lxml devs. The XPath compiler and engine are implemented by libxml2 and allow you to define your own XPath functions and even replace existing ones. As soon as that's available, you can't reason about the meaning of an XPath function call at compile time anymore, because (as Holger extensively showed) it depends on the runtime context in which it gets executed. I agree that you wouldn't normally replace the original XPath functions, but I do not really see a reason to prevent people from doing so. Compile time "validation" of function calls would get in the way then. That being said, feel free to discuss this on the libxml2 mailing list. All I can really give you here is secondary guesses about how it should be and why. Stefan
participants (2)
-
Alex Vincent -
Stefan Behnel