![](https://secure.gravatar.com/avatar/a72e34437ff2a048717b7b964940b0b3.jpg?s=120&d=mm&r=g)
Hi,
Is it a reasonable expectation that they act the same? (I think they haven't tested the code much with lxml 2, so basically they haven't exercised the first case... though looking at the code some I'm not sure it works with the second case either)
[...]
Currently, lxml.objectify is positioned as an API *on-top* of etree, although things that behave differently are duplicated already. I haven't made up my mind yet. However, I do feel that there may be more things that might want to behave different in the future, so having them duplicated from the beginning makes it a) easier to grow the different APIs in their respective direction, and b) easier for users to use them consistently inside the module/package API that they are using, without caring about the interaction with etree if they don't use it.
Mirroring the etree API completely in objectify might make the incautious user think that these modules can be used completely interchangeable, while they are not. And the difference are subtle, e.g. the indexing behaviour (sibling access in objectify, children access in etree), and will not necessarily produce easily detectable errors. So for an lxml.objectify that exposes a full etree-API, it should be stated very prominently that you can't just take your existing etree worker code and start using objectify instead. Holger -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser