Fwd: Re: [Zope3-dev] zope.etree comments

[Michael Kerrin]

I am not a PyPy sprint in Limerick and get seem to send mail - so I will try 
again.

Hi Martijn,

On Friday 25 August 2006 16:33, Martijn Faassen wrote:
> I just noticed the existence of zope.etree. Besides a minor comment on
> its use of 'zope' as the namespace package, which I believe is generally
> reserved for core components, I have the following more conceptual comment:
What name should I use, I have seen a lot of talk on this but never really
followed any of the threads to the end. If you (Martijn) say use X I will. I 
don't want to start another thread on this.

> There are currently three implementations of the ElementTree API:
>
> ElementTree  (original implementation in plain Python)
> cElementTree (same API, faster, C-code)
> lxml.etree   (same API but vastly extended, faster, dependency on
> libxml2 etc)
>
> The motivation of zope.etree appears to be to be able to swap out
> ElementTree with lxml for performance reasons. While as the developer of
> lxml the increased use of lxml makes me happy, I still wonder why this
> choice was made. Glancing through the code I cannot find a reference to
> cElementTree at all. I wonder why the choice wasn't made to simply swap
> out with cElementTree instead?

The only reason cElementTree isn't there is that I haven't installed
cElementTree on my laptop yet. It should be trivial to add this in though.

> After all, the reason to do this, as stated, is performance.
> cElementTree has performance, is easier to install than lxml (as it
> doesn't have dependencies), will ship with Python 2.5, and has the same
> API as ElementTree itself.
>
> The main reason to use lxml over cElementTree is not performance
> (sometimes it's faster, sometimes slower, depending on what you do) but
> is extended features - lxml has a huge featureset. Some of these
> features can of course also help with performance, but only if you use
> them.
>
> More features cannot be the reason for zope.etree however, as the whole
> point is to use lxml and ElementTree interchangably, right?

Exactly. If you need a feature that is only in lxml, just importing lxml is
probable the right thing to do.

All the zope.etree code is also in zope.webdav (it still is, as I haven't
removed it yet). I thought this part of zope.webdav was a good idea, and not
particular to webdav so this morning I had some time to write a README and I
decided to just upload it.

My motivation, is not just performance, is that I like ElementTree API and I
wanted to use it in zope.webdav. And I would also like to see zope.webdav has
a replacemenet to zope.app.dav at some point in the future. So I had the
problem to choice a ElementTree implementation so instead of choicing an
implementation I wrote zope.etree which doesn't tie zope.webdav to any one
implementation but lets the admins / developers choice which implementation
they want to use. The admins, developers who use zope.etree are the ones who
can quote performance, or what ever reason they want for their decision to
use lxml or cElementTree or plain elementtree. or whatever implementation.

I hope this answers your questions and I will try add cElementTree support
over the weekend.

Michael

> Regards,
>
> Martijn
>
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub:
> http://mail.zope.org/mailman/options/zope3-dev/michael.kerrin%40openapp.biz

--
Michael Kerrin

55 Fitzwilliam Sq.,
Dublin 2.

Tel: 087 688 3894

-------------------------------------------------------

-- 
Michael Kerrin

55 Fitzwilliam Sq.,
Dublin 2.

Tel: 087 688 3894