On Wednesday 04 June 2003 07:16 pm, alan milligan wrote:

Personally, I am a bit sceptical about the whole Interface concept. Fortunately because Python supports multiple inheritance, it's not like the Java mechanism. But it strikes me as being much too like the concept of a pure abstract base class in C++. But the reality is that this almost never happens, and it always seems like a good idea to start using this class for common methods. I do not have a problem with this and think that just declaring a function gives you little benefit when you could provide a definition as well - even a 'raise AssertionError, 'Implement me!' seems more useful :)

I think it depends on what they are used for. In my situation, I am defining objects that future 3rd party developers will likely have to subclass. But what methods and attributes do I promise to keep, and which do I plan to alter at need? Also, the interface concept allows me to specify what an object *behaves like* -- not what it *is*. Right now if I subclass from Folder, it isn't easy for me to tell this with introspection -- I have to *know* that a "Topic" is just an extended Zope folder. Interfaces will allow me to simply say that "Topic implements a Folder interface". Then it's easy to tell whether I can call certain methods on it. The "metatype" concept just isn't good enough for this, and inspecting __bases__ is too complicated. Anyway, what if I *don't* subclass from Folder? Maybe I just implement all the same methods. Interfaces lets me just say what it does in an unambiguous way. And since it's in the code, and there is a mechanism for checking that the interface is implemented (in fact I'm thinking of building in such a check into my installation process), this is a nice arrangement. The thing to realize is that interfaces are self-checking documentation, not code. Well, so far, they seem really nice, anway. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com