Bob Kline schrieb am 21.04.2017 um 16:26:
On Fri, Apr 21, 2017 at 9:10 AM, Stefan Behnel wrote:
Would it help you to get an XPath expression targeting the node in error?
That would be a perfect solution.
I can see two drawbacks of that proposal: it takes a bit of time to calculate that expression (even though we could store the UTF-8 C string in the end and postpone the conversion to a Python object), and it might not always be clear which tree to apply it to, e.g. in the case of XInclude failures or other cases where multiple trees are involved (schema imports?). But both could be considered acceptable.
I agree that postponing conversion (as you have done for a couple of the other properties) would be helpful. There might even be a way to let lxml know globally whether to collect this information at all (though I'll leave it to you to decide whether that optimization is worth the extra clutter).
This would be possible, but might require storing configuration in the thread-local context. I'd rather wait until it's clear that the slowdown is really not acceptable. We are talking about error cases here, after all.
I'm not sure I understand the second issue. Isn't libxml2 sort of making that decision for us, but giving us the xmlNode pointer, which we'd be passing to their xmlGetNodePath function?
I meant the user side, where you get an error back and an XPath expression with it, and then have to know what tree to apply the expression to in order to find the failing element. My intuition tells me that it will be clear most of the time, that's why I think it should be acceptable. Stefan