[lxml-dev] should lxml.html have the same API as lxml.etree?

[jholg at gmx.de]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20080310/298e3015/attachment.htm