ElementPath vs. XPath expression

Hello, I’m trying to select the last child of an element. However, I noticed the following with lxml 4.1.1 last = el.find("./*[last()]") returns the first child. last, *_ = el.xpath("./*[last()]") returns the last child. According to the documentation: http://effbot.org/zone/element-xpath.htm both should work though. Also, just out of curiosity, would the following have any advantage (perf?) over the above? *_, last = list(el) Thanks! Jens -- Jens Tröger http://savage.light-speed.de/

On Sat, Apr 21, 2018 at 08:47:55PM +0200, Stefan Behnel wrote:
I haven’t seen the last, = el.xpath(…) notation before, cheers! Looks like it’s almost the same as dismissing the tail of the list with *_ though. On Sat, Apr 21, 2018 at 08:39:18PM +0200, Stefan Behnel wrote:
Interesting. That sounds like a bug.
Oh ok, because I’ve been scratching my head quite a bit over that ;-)
*_, last = list(el)
That's fairly slow in comparison to any of the above.
Hmm… bummer. So the list() here under the covers iterates over el to create a new list? I assumed it would return a reference to the existing internal list, the one that is used for el[…] (i.e. the one used by __getindex__). Thanks for pointing that out, will fix. Cheers, Jens -- Jens Tröger http://savage.light-speed.de/

Jens Tröger schrieb am 21.04.2018 um 23:07:
The difference is that the star-unpacking splits the iterable into a first value and a list that contains the rest (which might be empty), and unpacking to a tuple of fixed length (length 1 in this case) will fail for anything that's not an iterable of the exact length, thus uncovering more of the potential bugs in the XPath expression..
That's what your code requests, yes.
There is no internal Python list. But regardless, whenever you say "list(something)", it will create a new list of whatever content that "something" has. Stefan

On Sat, Apr 21, 2018 at 08:47:55PM +0200, Stefan Behnel wrote:
I haven’t seen the last, = el.xpath(…) notation before, cheers! Looks like it’s almost the same as dismissing the tail of the list with *_ though. On Sat, Apr 21, 2018 at 08:39:18PM +0200, Stefan Behnel wrote:
Interesting. That sounds like a bug.
Oh ok, because I’ve been scratching my head quite a bit over that ;-)
*_, last = list(el)
That's fairly slow in comparison to any of the above.
Hmm… bummer. So the list() here under the covers iterates over el to create a new list? I assumed it would return a reference to the existing internal list, the one that is used for el[…] (i.e. the one used by __getindex__). Thanks for pointing that out, will fix. Cheers, Jens -- Jens Tröger http://savage.light-speed.de/

Jens Tröger schrieb am 21.04.2018 um 23:07:
The difference is that the star-unpacking splits the iterable into a first value and a list that contains the rest (which might be empty), and unpacking to a tuple of fixed length (length 1 in this case) will fail for anything that's not an iterable of the exact length, thus uncovering more of the potential bugs in the XPath expression..
That's what your code requests, yes.
There is no internal Python list. But regardless, whenever you say "list(something)", it will create a new list of whatever content that "something" has. Stefan
participants (2)
-
Jens Tröger
-
Stefan Behnel