Татаринов Андрей wrote:
> This is all very interesting, but the only thing I can't understand
> what does it have in common with lxml?
>
> In fact, for a quiet some time I do not understand the goal of lxml
> project. At first it was "ElementTree on top of libxml2", after it
> becames more and more bloated with ET-Incompatible API, now, program
> that uses lxml cannot be easy ported back to ElementTree.
I don't think it's fair to say that our API is ET-incompatible. lxml's
API is as compatible to ElementTree as we can make it, and we've
expended quite some effort in making it be so.
We've *extended* the API to expose a host of features in libxml2 and
libxslt. For instance, we expose namespace prefixes in lxml.etree where
ET does not. I do not consider these extensions as bloat but as
important functionality.
The API also got extended with a facility to hook in custom element
classes for particular elements. This is an extension to the ET model
which due to its nature needs to be done in the core. I think this is a
nice and powerful feature.
Stefan has now built other facilities on top of this that are unique to
lxml. This is where I asked about goals.
> May be it's time to split into ET-implementations and lxml-specific?
> Or to say "lxml is no more just an ElementTree implementation, but a
> separate project with it's own ideoms"?
lxml has always been *more* than just an ElementTree implementation; if
it were just an ElementTree implementation there'd be no point in doing
our work. It's an ElementTree implementation that exposes a host of XML
technologies implemented in libxml2 and libxslt. It's a Python XML
library with support for XPath, XSLT, Relax NG, and so on.
The objectify extensions, yes, we could present as a separate project
with its own idioms.
Regards,
Martijn
_______________________________________________
lxml-dev mailing list
lxml-dev@xxxxxxxxxxxxx
http://codespeak.net/mailman/listinfo/lxml-dev
|
