On Tue, Dec 15, 2009 at 1:11 PM, Tom Davis <[email protected]> wrote: >> >> we aren't really using them for anything > > > Well, they *should* be used to validate a driver, as was the original > intent.
We use verifyObject a bunch: https://svn.apache.org/repos/asf/incubator/libcloud/trunk/test/test_base.py I have not found it that useful. It only seems to check that it has the "implements(IBlah)" clause and does not actually do any sort of internal object introspection. Maybe I am using it wrong, but it seems like testing the interfaces with normal unit tests would do the same thing. > If this isn't implemented it would be trivial to add tests for this > purpose. It also allows us to automate discovery / validation of drivers > rather than manually list them out in some module that needs to be edited > each time one is added or removed (which was also an initial intention > though meant to be added later on). How would auto discovery work with zope? > I think the value-add of both documenting and validating a driver actually > eases the development of them, not complicates it. I feel like we could just document the base class. The testing stuff, as mentioned above, does not seem to be that big of a win. While I love the idea of interfaces, I'm not 100% sold it is that big of a win over just solid, well documented, base classes coupled with a good test suite. It was great when we had *no* structure... but now we have a solid set of base classes which seem to be working well. -Alex > On Tue, Dec 15, 2009 at 2:43 PM, Jeremy Orem <[email protected]> wrote: > >> Right now we have a zope interface dependency. I'd like to remove this, >> because: >> >> * we aren't really using them for anything >> * they can be a little confusing to people who haven't used zope >> interfaces elsewhere >> * documenting libcloud with sphinx isn't so automatic when interfaces >> are being used >> * we haven't made a release, so right now would be a great time to remove >> them >> >> Is anyone opposed to this? >> >> >> Thanks, >> >> Jeremy >> > -- co-founder, cloudkick.com twitter.com/cloudkick 541 231 0624
