[Zope3-dev] zope.etree comments

[Martijn Faassen]

Fred Drake wrote:
> On 8/25/06, Michael Kerrin <michael.kerrin at openapp.biz> 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