Martijn Faassen wrote:
Stefan Behnel wrote:
One little hack is that it only copies the element, it does not do deep-copying. It should therefore be possible to access higher ancestors that are not below the _context_node of the respective ElementTree via e.g. an XSLT (like via <copy-of select="ancestors::node()"/>). I didn't test that, but I believe it is not too bad, since it is a rather rare case and somehow even fits the ElementTree idea of Elements being 'free'.
Hm, this is rather worrisome. I would expect an ElementTree to be a whole document and this could potentially lead to odd effects depending on the way the XSLT engine works -- basically due to this hack, the operation is performed on a tree that is not actually correct and this could lead to all kinds of unexpected behavior...
I find the behaviour of ElementTrees eating Elements much more surprising, especially for people knowing the original ElementTree. Note that it is perfectly reasonable for the root element of an ElementTree to have a parent. You must not forget that it is now possible for elements to be in multiple ElementTrees at the same time, just like in Fredrik's ElementTree. So, once you have understood that Elements can be part of different ElementTrees without loosing their global position in a document (which is basically how Fredrik's ElementTree works), it's even relatively obvious that there may be ancestors that are not part of the current ElementTree that is being worked on. I would even say it should be enough to document that somewhere. People will understand it. Then the 'unexpected' behaviour would no longer be surprising. Also, you should not forget that it is really, really rare that XSLTs actually look for parents. Almost all stylesheets I have seen so far were based on descend matching. That's how XSLT templates work, you apply them to the children of nodes. And since the (fake) root node is really a root node of a complete document (except for the second level parent pointers), this should not pose any problems at all. It's even less a problem for RelaxNG, where AFAICT the algorithms dictates descend matching.
Additionally, how does the getparent() operation fare in this context? The parent of a node that's wrapped directly in an ElementTree might be something that's not even supposed to be in that tree, which is really unexpected. Or is there a reason this doesn't happen?
This is different, since it does not depend on libxml2, so there is no fake document involved. I actually think that this was Fredrik's reasoning behind *not* providing a getparent() function at all. However, in the context of lxml, getparent() is sufficiently useful to accept this behaviour.
I know, it might sound a little confusing at first, but I hope you got the idea.
Yes, I think so, thank you for the explanation. I now need to consider costs and gains of this approach compared to the one lxml is taking currently...
Sure, but I really think the gains are much higher than the explainable parent problem that we introduce. I think this would be much easier to understand for people that are new to lxml but know ElementTree, than for people that have used lxml for too long... Stefan