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

[Stefan Behnel]

Hi Ian,

Ian Bicking wrote:
> I've noticed in html5lib that they do (in html5lib.treebuilder.etree_lxml):
> 
> try:
>      import lxml.html as etree
> except ImportError:
>      from lxml import etree
> 
> with the expectation that the two work the same way.  They don't work 
> the same, specifically there's no etree.Comment.
> 
> 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)

I thought about that for lxml.objectify, too. I mean, you could import
basically everything from etree into the package/module namespace and be done.
The question of having an "__all__" or not is related to this.

The thing that made me think about this was tostring(). There is no tostring()
in objectify, so it's unlikely that you will ever be able to use it without
also importing etree.

But on the other hand, if you agree to import some names, where do you draw
the line? Would you want to provide XSLT and RelaxNG as well? What about all
the exceptions? And I'm absolutely sure there will be the day where I forget
to add an import (or assignment) somewhere when I add a new name to etree.

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.

Any more opinions on this?

Stefan