[Zope3-dev] zope.etree comments
Hi there, 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: 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? 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? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Fwd: Re: [Zope3-dev] zope.etree comments
Sorry for the duplicate mails - it turns out I can send mail it is just terrible slow. Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Fwd: Re: [Zope3-dev] zope.etree comments
Michael Kerrin wrote: I am not a PyPy sprint in Limerick Good to know. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
On Friday 25 August 2006 18:10, Fred Drake wrote: On 8/25/06, Michael Kerrin [EMAIL PROTECTED] wrote: 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 say use X I will. I don't want to start another thread on this. I think the name is fine. There are packages under zope that don't get checked out as core, too, so no need to change it. Ignore the namespace packages arguments, those are decoys. Exactly. If you need a feature that is only in lxml, just importing lxml is probable the right thing to do. Yes. I think a wrapper that understands what versions of ElementTree might be available and that implement the basic ElementTree API makes sense. With the introduction of xml.etree in Python 2.5, the number of possible spellings goes up yet again. Moving all the import cruft to a single place makes sense. I will note that Zope 3 doesn't even come close to being happy with Python 2.5. I don't have time to work on that, and a number of discussions are probably needed to work everything out. I should start a wiki page with notes on what needs to change, but that's a separate discussion. I tried running the Zope3 tests against python2.5 also. It didn't work out to well :-( But the my instance did seem to work to a point. It might be worth my time replacing the Python2.5 support I have with the cElementTree and droping Python2.5 until this stabilizes Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
Fred Drake wrote: On 8/25/06, Michael Kerrin [EMAIL PROTECTED] wrote: 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 say use X I will. I don't want to start another thread on this. I think the name is fine. There are packages under zope that don't get checked out as core, too, so no need to change it. Ignore the namespace packages arguments, those are decoys. I wasn't suggesting it get changed right away or anything, but I do think we have been treating the 'zope' core package namespace is a bit special compared to all the other ones. :) It's the core after all. I also wonder how easy it is to install something that's not shipped with the core into the core. Perhaps after eggs happen it won't be important anymore, but perhaps we want to apply special standards to what's in the core, I don't know. If we can all use 'zope' that should make the choice for a namespace package very easy. :) Exactly. If you need a feature that is only in lxml, just importing lxml is probable the right thing to do. Yes. I think a wrapper that understands what versions of ElementTree might be available and that implement the basic ElementTree API makes sense. With the introduction of xml.etree in Python 2.5, the number of possible spellings goes up yet again. Moving all the import cruft to a single place makes sense. Yes, that makes sense, if you have a need to rely on one library or another for the same API. I'm not sure whether this is an important need, though... One could say this anticipates Python 2.5, but once Python 2.5 is released and Zope starts to require it, making zope.webdav use it could be as simple as just changing a few import statements anyway. Anyway, no big deal, it just surprised initially me that this kind of pluggability was thought to be necessary so I wanted to drop some remarks on it. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
On 8/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: also wonder how easy it is to install something that's not shipped with the core into the core. From where I sit (behind fancy buildout systems!), it's just as easy to add another separately-developed zope.something package as it is to add a zc.something package. There are a number of non-core zope.something packages on svn.zope.org now, and these definately see use in one or more projects. Yes, that makes sense, if you have a need to rely on one library or another for the same API. I'm not sure whether this is an important need, though... One could say this anticipates Python 2.5, but once Python 2.5 is released and Zope starts to require it, making zope.webdav use it could be as simple as just changing a few import statements anyway. Use are require are distinct. We probably want to support Python 2.5 before we require it. That would be ideal, at any rate. My interest is in keeping all the import dances out of application code; I find them terribly distracting, and keeping the reasoning behind specific aspects of such a dance straight can be difficult. This isolates it from the application, avoiding duplication of the import dance. That said, it's probably also valuable *not* to exclude lxml.etree from the dance so that applications don't accidentally become dependent on the extended functionality. Or it could be wrapped to prevent access to additional features, but that seems overkill. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
