Python Coding Standards – Should Private Methods Always Use Underscore Prefix in Python?

If you stop to think about it, you'll see that an interface really isn't semantically much different from an abstract class:

• Both have methods and/or properties (behaviour);
• Neither should have non-private fields (data);
• Neither can be instantiated directly;
• Deriving from one means implementing any abstract methods it has, unless the derived type is also abstract.

In fact, the most important distinctions between classes and interfaces are:

• Interfaces cannot have private data;
• Interface members cannot have access modifiers (all members are "public");
• A class can implement multiple interfaces (as opposed to generally being able to inherit from only one base class).

Since the only particularly meaningful distinctions between classes and interfaces revolve around (a) private data and (b) type hierarchy - neither of which make the slightest bit of difference to a caller - it's generally not necessary to know if a type is an interface or a class. You certainly don't need the visual indication.

However, there are certain corner cases to be aware of. In particular, if you're using reflection, interception, dynamic proxies/mixins, bytecode weaving, code generation, or anything that involves messing directly with the environment's typing system or code itself - then it's very helpful and sometimes necessary to know right off the bat whether you're dealing with an interface or a class. You clearly don't want your code to mysteriously fail because you tried to add a class, rather than an interface, as a mixin.

For typical, vanilla, run-of-the-mill business logic code, though, the distinctions between abstract classes and interfaces do not need to be advertised because they'll never come into play.

All of this being said, I tend to prefix my C# interfaces with I anyway because that is the .NET convention used and advocated by Microsoft. And when I'm explaining coding conventions to a new developer, it's far less hassle to just use Microsoft's rules than to explain why we have our own "special" rules.

Let me give some guiding principles.

Principle #1. As outlined in http://docs.python.org/2/reference/simple_stmts.html the performance overhead of asserts can be removed with a command line option, while still being there for debugging. If performance is a problem, do that. Leave the asserts. (But don't do anything important in the asserts!)

Principle #2. If you're asserting something, and will have a fatal error, then use an assert. There is absolutely no value in doing something else. If someone later wants to change that, they can change your code or avoid that method call.

Principle #3. Do not disallow something just because you think it is a stupid thing to do. So what if your method allows strings through? If it works, it works.

Principle #4. Disallow things that are signs of likely mistakes. For instance consider being passed a dictionary of options. If that dictionary contains things that are not valid options, then that's a sign that someone didn't understand your API, or else had a typo. Blowing up on that is more likely to catch a typo than it is to stop someone from doing something reasonable.

Based on the first 2 principles, your second version can be thrown away. Which of the other two you prefer is a matter of taste. Which do you think more likely? That someone will pass a non-customer to add_customer and things will break (in which case version 3 is preferred), or that someone will at some point want to replace your customer with a proxy object of some kind that responds to all of the right methods (in which case version 1 is preferred).

Personally I've seen both failure modes. I'd tend to go with version 1 out of the general principle that I'm lazy and it is less typing. (Also that kind of failure usually tends to show up sooner or later in a fairly obvious way. And when I want to use a proxy object, I get really annoyed at people who have tied my hands.) But there are programmers I respect who would go the other way.