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