What is the difference between abstract class and interface in Python?

An interface, for an object, is a set of methods and attributes on that object.

In Python, we can use an abstract base class to define and enforce an interface.

Using an Abstract Base Class

For example, say we want to use one of the abstract base classes from the collections module:

import collections
class MySet(collections.Set):
    pass

If we try to use it, we get an TypeError because the class we created does not support the expected behavior of sets:

>>> MySet()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class MySet with abstract methods
__contains__, __iter__, __len__

So we are required to implement at least __contains__, __iter__, and __len__. Let's use this implementation example from the documentation:

class ListBasedSet(collections.Set):
    """Alternate set implementation favoring space over speed
    and not requiring the set elements to be hashable. 
    """
    def __init__(self, iterable):
        self.elements = lst = []
        for value in iterable:
            if value not in lst:
                lst.append(value)
    def __iter__(self):
        return iter(self.elements)
    def __contains__(self, value):
        return value in self.elements
    def __len__(self):
        return len(self.elements)

s1 = ListBasedSet('abcdef')
s2 = ListBasedSet('defghi')
overlap = s1 & s2

Implementation: Creating an Abstract Base Class

We can create our own Abstract Base Class by setting the metaclass to abc.ABCMeta and using the abc.abstractmethod decorator on relevant methods. The metaclass will be add the decorated functions to the __abstractmethods__ attribute, preventing instantiation until those are defined.

import abc

For example, "effable" is defined as something that can be expressed in words. Say we wanted to define an abstract base class that is effable, in Python 2:

class Effable(object):
    __metaclass__ = abc.ABCMeta
    @abc.abstractmethod
    def __str__(self):
        raise NotImplementedError('users must define __str__ to use this base class')

Or in Python 3, with the slight change in metaclass declaration:

class Effable(object, metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def __str__(self):
        raise NotImplementedError('users must define __str__ to use this base class')

Now if we try to create an effable object without implementing the interface:

class MyEffable(Effable): 
    pass

and attempt to instantiate it:

>>> MyEffable()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class MyEffable with abstract methods __str__

We are told that we haven't finished the job.

Now if we comply by providing the expected interface:

class MyEffable(Effable): 
    def __str__(self):
        return 'expressable!'

we are then able to use the concrete version of the class derived from the abstract one:

>>> me = MyEffable()
>>> print(me)
expressable!

There are other things we could do with this, like register virtual subclasses that already implement these interfaces, but I think that is beyond the scope of this question. The other methods demonstrated here would have to adapt this method using the abc module to do so, however.

Conclusion

We have demonstrated that the creation of an Abstract Base Class defines interfaces for custom objects in Python.

Communicate the big picture

To communicate the big picture about a set of classes that are supposed to work together, you may consider the following:

• An UML class diagram (structure), to explain the involved classes, their responsibilities, and their relationships. In your case, you would typically document the operations (UML term for methods) that each class has to provide for your interaction to work.
• An UML sequence diagram (dynamics), to explain how involved objects of these classes interact by creating each other, and communicating (i.e. calling their operations). Keep diagrams simple, you may make several such diagram, each explaining a specific scenario.

These two simple diagrams help to grasp at a glance the classes involved and how they work together.

Improve your customer/developer's experience

It's not graphical overview vs. self-explanatory code: it's both together. The diagrams are the map that tells where to look for the treasure. The users can then navigate quickly to the related parts with their to find more information. But without the map, the customers might take a lot longer to figure out how all the parts fit together.

To maximise the experience:

• Keep it lean: show only on the key elements of your design. Don't put all attributes and methods; this would only lead to unreadable diagrams that might frighten away your audience ;-)
• Ideally, you'd use the the diagrams together with a short explanatory text on the landing page of your documentation,
• You may provide also an API documentation generated automatically from your comments.

If you're using python, you can give a quick trial at PyReverse (it's part of Pylint, a tool you should consider if you're making mission critical SCADA systems) : it generates automatically some UML class diagrams. But usually, for a design overview, you'll be as fast drawing it from scratch.

Abstract class or not?

Form is a class since it provides an implementation for some methods. It's probably not an abstract class by the book, if it can be instantiated.

Nevertheless, nothing prevents you to show it as abstract on the diagram, to underline that a subclass must be created to make it work. Personally, I'd show is as a normal class and would show one subclass in the diagram that shows the operation that should/could be overridden.