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