![](https://secure.gravatar.com/avatar/8b97b5aad24c30e4a1357b38cc39aeaa.jpg?s=120&d=mm&r=g)
Hi, jholg@gmx.de wrote:
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.
That's not really something I'm worried about. I think it's clear from the docs (and intuitively from etree and objectify being separate modules) that they are not interchangeable. I think the real question is: should users need to import etree, when what they actually work with is objectify or lxml.html? And I think duplicating the module content and having to import only one module/package makes it even clearer that they /have/ separate APIs than the current mix of "partly etree, partly objectify" can. It allows users to stay inside the world of one tool, without even having to think about the differences to another tool that they do not care about (or at least should not have to). Stefan