On Wed, Mar 19, 2025 at 9:17 PM Stefan Behnel <stefan...@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
_______________________________________________ lxml - The Python XML Toolkit mailing list -- lxml@python.org To unsubscribe send an email to lxml-le...@python.org https://mail.python.org/mailman3/lists/lxml.python.org/ Member address: arch...@mail-archive.com
