I agree with you completely. Python makes it hard to group behaviors akin to the Java interface. I see where interfaces make sense when building a system, but coming from a Java background, I always try to organize my Python code like a Java program. It's hard to break old habits, I guess.

An application or so a go I tried to use an internal dictionary to store objects for "implemented" interfaces. I overrode the getattr method in the base class to check this dictionary for objects of a certain type and run the correct method, if the dictionary had an object with a method. It was heavy, bloated, and problematic, but I think the idea was a sound one that's worthy of further exploration.

My 2% of a dollar.
Keith

I think the interface systems that exist -- namely Zope 3's and PyProtocols -- address a lot of the issues you are considering. They also deal with has-a vs. is-a in a novel way (adaptation), which is perhaps more general than interfaces. PyProtocols especially emphasized adaptation.

That said, using them will be as easy as simply creating a base class that raises NotImplementedError for all its methods. There's a significant overhead to being explicit in your interfaces; but if you're already convinced of the benefit, then maybe you're ready to make those changes.

Ned: why not just define ExecutableOneWay and ExecutableTheOtherWay as separate interfaces? Wouldn't that fix your problem?

I realize you say that's the path to "one interface per method", but don't all interfaces walk that path eventually? I mean, how else would you expect to do it in Java or C++? Really, in my experience, it's uncommon to have really wide interfaces. Most are in the 1-5 method range, I think, and that's a *good* thing, because it means you're keeping concerns separate.

Now, if you want to use PyProtocols, you can usually separate these concerns on either a class-by-class or even instance-by-instance basis using adapters, but of course your code may become somewhat more verbose due to the addition of adapter classes. But your code will also be more modular, because the details specific to an entire area of concern can then be factored out from the pure "domain model" code.

Doesn't the idea of explicit interfaces go against the dynamic nature of Python?

My gut feeling is you are trying to make Python be something it doesn't want to be. That's probably not a good thing.