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.


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.


Zope3-dev mailing list

Reply via email to