@Oddthinking's answer is not wrong, but I think it misses the real, practical reason Python has ABCs in a world of duck-typing.

Abstract methods are neat, but in my opinion they don't really fill any use-cases not already covered by duck typing. Abstract base classes' real power lies in the way they allow you to customise the behaviour of isinstance and issubclass. (__subclasshook__ is basically a friendlier API on top of Python's __instancecheck__ and __subclasscheck__ hooks.) Adapting built-in constructs to work on custom types is very much part of Python's philosophy.

Python's source code is exemplary. Here is how collections.Container is defined in the standard library (at time of writing):

class Container(metaclass=ABCMeta):
    __slots__ = ()

    @abstractmethod
    def __contains__(self, x):
        return False

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Container:
            if any("__contains__" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

This definition of __subclasshook__ says that any class with a __contains__ attribute is considered to be a subclass of Container, even if it doesn't subclass it directly. So I can write this:

class ContainAllTheThings(object):
    def __contains__(self, item):
        return True

>>> issubclass(ContainAllTheThings, collections.Container)
True
>>> isinstance(ContainAllTheThings(), collections.Container)
True

In other words, if you implement the right interface, you're a subclass! ABCs provide a formal way to define interfaces in Python, while staying true to the spirit of duck-typing. Besides, this works in a way that honours the Open-Closed Principle.

Python's object model looks superficially similar to that of a more "traditional" OO system (by which I mean Java*) - we got yer classes, yer objects, yer methods - but when you scratch the surface you'll find something far richer and more flexible. Likewise, Python's notion of abstract base classes may be recognisable to a Java developer, but in practice they are intended for a very different purpose.

I sometimes find myself writing polymorphic functions that can act on a single item or a collection of items, and I find isinstance(x, collections.Iterable) to be much more readable than hasattr(x, '__iter__') or an equivalent try...except block. (If you didn't know Python, which of those three would make the intention of the code clearest?)

That said, I find that I rarely need to write my own ABC and I typically discover the need for one through refactoring. If I see a polymorphic function making a lot of attribute checks, or lots of functions making the same attribute checks, that smell suggests the existence of an ABC waiting to be extracted.

*without getting into the debate over whether Java is a "traditional" OO system...

Addendum: Even though an abstract base class can override the behaviour of isinstance and issubclass, it still doesn't enter the MRO of the virtual subclass. This is a potential pitfall for clients: not every object for which isinstance(x, MyABC) == True has the methods defined on MyABC.

class MyABC(metaclass=abc.ABCMeta):
    def abc_method(self):
        pass
    @classmethod
    def __subclasshook__(cls, C):
        return True

class C(object):
    pass

# typical client code
c = C()
if isinstance(c, MyABC):  # will be true
    c.abc_method()  # raises AttributeError

Unfortunately this one of those "just don't do that" traps (of which Python has relatively few!): avoid defining ABCs with both a __subclasshook__ and non-abstract methods. Moreover, you should make your definition of __subclasshook__ consistent with the set of abstract methods your ABC defines.

There are generally many good ways to implement this. However, everyone have their own preferences, so mostly which of the following you use is up to you. Here's the three approaches:

1. Do it the way you are currently implementing it. For a basic structure, it'll be something similar to this:

from abc import ABCMeta

class Abstract(metaclass=ABCMeta):
    def write(self):
        raise NotImplementedError()

class Mixin():
    def meth1(self, *args, **kwargs):
        """ do something here"""

class ActualUsefulImplementedClass(Abstract, Mixin):
    """ write your methods here. You will have access to all the helper methods of the mix-in class."""

2. Implementing the methods as functions (presumably in another file in the same directory as the current file) and call them from inside the class will also be OK:

from abc import ABCMeta
from helpers import func1, func2, func3, ...

class Abstract(metaclass=ABCMeta):
    def write(self):
        raise NotImplementedError()

class ActualUsefulImplementedClass(Abstract, Mixin):
    """ write your methods here. Access the helper functions imported above directly in your methods."""
    # for example
    def do_something(self, *args, **kwargs):
        func1(*args)

This approach does have it's drawbacks, namely:

• If by any chance your helper methods acts on an instance of some self-defined class, then this approach will break. Of course, you can pass-in the instance as an argument, but that is a very, very bad idea in terms of software engineering ideas and principles.
• Also, if you want to inherit them once and have access to them without additional code for all of the ActualUsefulImplementedClass's subclasses, then this approach doesn't fit the bill.
• Finally, if you want a strictly OOP approach, or don't want the helper functions to pollute your current module scope's namespace, then this isn't the best fit as well.

3. Similar to the first approach stated above (number 1), but create another middle-level class that doesn't use the mix-in. It will be something like the following:

from abc import ABCMeta

class Abstract(metaclass=ABCMeta):
    def write(self):
        raise NotImplementedError()

class Mixin():
    def meth1(self, *args, **kwargs):
        """ do something here"""

class MiddleMan(Abstract):
    """ write your methods here. You will not have access to the helper methods of the mix-in class."""

class ActualUsefulImplementedClass(MiddleMan, Mixin):
    """ You will have both the actual method implementations and the helper methods here without much or any code."""

However, the above code will only work if you don't need the helper methods inside your methods' implementations and only need them outside of the class. If you need them inside the methods' code, then use the first approach. If you only need the helpers outside of the class, then use this approach.

Note: I use docstrings in the line immediately after the class or method definition line whenever applicable. It describes some of the abilities and limitations of the approach, so please read them as well.