On Wed, Mar 19, 2025 at 9:17 PM Stefan Behnel <stefan_ml@behnel.de> wrote:
Hi,
Yes, that seems useless and unintended. I'll change it for lxml 6.0.
Thanks for reporting this.
Stefan
Awesome. Thanks Stefan. I see you went with my proposed fix. The commit looks good. The issue is solved, but for completeness, here is another possible fix I thought of later. You could change .xpath() and etree.XPath() itself so that the expression "string(...)" always returns a plain str. 'Smart' strings will only be returned (as elements of a Python list) when the XPath result is a node set containing text/cdata/attribute nodes. This could be implemented by removing the _elementStringResultFactory() call in _unwrapXPathObject() when xpathObj.type == xpath.XPATH_STRING. I'm not certain if this alternative fix is a good idea. On one hand, you could argue that a smart string is only meaningful when it has additional information about its origin node, not XPATH_STRING, and hence that every user of "string(...)" is receiving 'smart' strings by accident. On the other hand, it's a bigger change and it would require updating the documentation, which does currently say a 'smart' string is returned whenever the XPath expression has a string result. What do you think? Tomi