Stefan Behnel wrote:
One more thing I wanted to stress.
Stefan Behnel wrote:
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 forgot to stress that we *cannot* remove the restriction of Elements being only in a single *document* at a time, which ET does *not* enforce at all. This is the price we pay for using libxml and the reason why getparent() makes sense in lxml and not in ET.
Right.
We can, however, remove the API divergence for Elements being in multiple ElementTrees - at the cost of making getparent() ignorant to ElementTrees.
If compatibility with ET is the goal, I consider this the right trade-off.
I'm not debating anything you said, just trying to think through the implications. The risk exists in the current setup that an algorithm is used somewhere inside libxml2 that takes the parent, and that we break the expectations of this with the current approach. I think it should be possible to create a _fakeRootDoc variety that actually changes the parent pointer temporarily as well, returning the original parent so we can put it back when we destroy the root doc. As these two are actually part of an atomic operation I think this should work, correct? That would at least eliminate concerns about possible algorithms somewhere in libxml2 using the parent pointer. The getparent() issue would still remain. I want to think this through for a bit too. Regards, Martijn