libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Davis <...@dislocatedday.com>
Subject Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Date Tue, 15 Dec 2009 22:53:50 GMT
Yeah, I would never rely on the likes of directory sniffing. You're also
making the assumption that anything in the drivers directory contains a
driver, the connection class is named a certain way, etc. It's full of too
many holes. Throwing out the subject of interfaces entirely, this is still
much more reliably achieved by a metaclass.

On Tue, Dec 15, 2009 at 5:44 PM, Paul Querna <paul@querna.org> wrote:

> On Tue, Dec 15, 2009 at 1:41 PM, Ian Bicking <ianbicking@gmail.com> wrote:
> > On Tue, Dec 15, 2009 at 3:11 PM, Tom Davis <tom@dislocatedday.com>
> wrote:
> >> documenting libcloud with sphinx isn't so automatic when interfaces are
> >>> being used
> >>
> >>
> >> A trivial fix; a Sphinx extension for documenting interfaces already
> exists.
> >>  See: this ticket<
> http://bitbucket.org/birkenfeld/sphinx/issue/85/minimal-support-for-zopeinterface
> >(specifically
> >> the finished extension:
> >> autointerface_.py <
> http://bitbucket.org/m//attch/2009/02/autointerface_.py>)
> >>
> >> I can't argue that now isn't a good time, but I still feel they are (and
> can
> >> be made more) useful. For one, they can assist in getting rid of the *
> >> providers.py* file entirely. A simple metaclass which functions as a
> mount
> >> coupled with interface verification (we don't want to provide a driver
> that
> >> doesn't yet implement the API) fixes the need for manually listing /
> >> commenting drivers, not to mention the ugly static paths / names that
> are
> >> going on there.
> >
> > This seems like it can be resolved anyway, and interfaces don't seem
> > like a particularly easy easy way to solve the problem.
> >
> > First, you could just import the drivers directly instead of the
> > get_driver indirection.  The only thing get_driver gives you is the
> > ability to lazy-load something based on fixed symbols.
> >
> > Second, you could have a simple reflection API, like:
> >
> > def drivers():
> >    """Returns a list of drivers (by name)"""
> >    return [
> >        os.path.splitext(name)[0]
> >        for name in os.listdir(os.path.join(os.path.dirname(__file__),
> > 'drivers')))
> >        if name.endswith('.py') and name != '__init__.py']
>
>
> Would this interface work on google app engine or similiar
> enviroments?  I ddin't think things like os.listdir etc would be
> expected to work?
>
> Thanks,
>
> Paul
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message