From the docs:

A class that has a metaclass derived from ABCMeta cannot be instantiated unless all of its abstract methods and properties are overridden.

Conversely, this means that any class with no abstract methods or properties like your AbstractClass can be instantiated.

If you want to disallow instantiation of the topmost parent class, you can write a custom class that performs a type check in its __new__ method:

class SubclassOnlyABC(object):
    __metaclass__ = abc.ABCMeta

    def __new__(cls, *args, **kwargs):
        if cls.__bases__ == (SubclassOnlyABC,):
            msg = 'Abstract class {} cannot be instantiated'.format(cls.__name__)
            raise TypeError(msg)

        return super(SubclassOnlyABC, cls).__new__(cls, *args, **kwargs)

class AbstractClass(SubclassOnlyABC):
    pass

class ChildClass(AbstractClass):
    pass

ChildClass()  # works because it's a child class of an abstract class
AbstractClass()  # throws TypeError because its parent class is "object"

You can also write a __new__ method that prevents instantiation of classes with no abstract methods:

class NonEmptyABC(object):
    __metaclass__ = abc.ABCMeta

    def __new__(cls, *args, **kwargs):
        # check if ANY abstractmethod exists
        for parentcls in cls.__mro__:
            if any(getattr(attr, '__isabstractmethod__', False)
                               for attr in vars(parentcls).values()):
                break
        else:
            msg = 'Abstract class {} cannot be instantiated'.format(cls.__name__)
            raise TypeError(msg)

        return super(NonEmptyABC, cls).__new__(cls, *args, **kwargs)

class EmptyAbstractClass(NonEmptyABC):
    pass

class NonemptyAbstractClass(NonEmptyABC):
    @abc.abstractmethod
    def foo(self):
        pass

class NonemptyChild(NonemptyAbstractClass):
    def foo(self):
        pass

NonemptyChild()  # works because "foo" is an abstractmethod
EmptyAbstractClass()  # throws TypeError because there are no abstractmethods

Are you using python3 to run that code? If yes, you should know that declaring metaclass in python3 have changes you should do it like this instead:

import abc

class AbstractClass(metaclass=abc.ABCMeta):

  @abc.abstractmethod
  def abstractMethod(self):
      return

The full code and the explanation behind the answer is:

import abc

class AbstractClass(metaclass=abc.ABCMeta):

    @abc.abstractmethod
    def abstractMethod(self):
        return

class ConcreteClass(AbstractClass):

    def __init__(self):
        self.me = "me"

# Will get a TypeError without the following two lines:
#   def abstractMethod(self):
#       return 0

c = ConcreteClass()
c.abstractMethod()

If abstractMethod is not defined for ConcreteClass, the following exception will be raised when running the above code: TypeError: Can't instantiate abstract class ConcreteClass with abstract methods abstractMethod

Before abc was introduced you would see this frequently.

class Base(object):
    def go(self):
        raise NotImplementedError("Please Implement this method")


class Specialized(Base):
    def go(self):
        print "Consider me implemented"

Use the abc module to create abstract classes. Use the abstractmethod decorator to declare a method abstract, and declare a class abstract using one of three ways, depending upon your Python version.

In Python 3.4 and above, you can inherit from ABC. In earlier versions of Python, you need to specify your class's metaclass as ABCMeta. Specifying the metaclass has different syntax in Python 3 and Python 2. The three possibilities are shown below:

Copy# Python 3.4+
from abc import ABC, abstractmethod
class Abstract(ABC):
    @abstractmethod
    def foo(self):
        pass

Copy# Python 3.0+
from abc import ABCMeta, abstractmethod
class Abstract(metaclass=ABCMeta):
    @abstractmethod
    def foo(self):
        pass

Copy# Python 2
from abc import ABCMeta, abstractmethod
class Abstract:
    __metaclass__ = ABCMeta

    @abstractmethod
    def foo(self):
        pass

Whichever way you use, you won't be able to instantiate an abstract class that has abstract methods, but will be able to instantiate a subclass that provides concrete definitions of those methods:

>>> Abstract()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class Abstract with abstract methods foo
>>> class StillAbstract(Abstract):
...     pass
... 
>>> StillAbstract()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class StillAbstract with abstract methods foo
>>> class Concrete(Abstract):
...     def foo(self):
...         print('Hello, World')
... 
>>> Concrete()
<__main__.Concrete object at 0x7fc935d28898>

I've used this before in cases where it was possible to have the concrete implementation, but I wanted to force subclass implementers to consider if that implementation is appropriate for them.

One specific example: I was implementing an abstract base class with an abstract factory method so subclasses can define their own __init__ function but have a common interface to create them. It was something like

class Foo(ABC):
    def __init__(self, a, b, c):
        self.a = a
        self.b = b
        self.c = c

    @classmethod
    @abstractmethod
    def from_args(cls, a, b, c) -> "Foo":
        return cls(a, b, c)

Subclasses usually only need a subset of the arguments. When testing, it's cumbersome to access the framework which actually uses this factory method, so it's likely someone will forget to implement the from_args factory function since it wouldn't come up in their usual testing. Making it an abstractmethod would make it impossible to initialize the class without first implementing it, and will definitely come up during normal testing.

After some thought, I think the second code snippet does not use the Factory method as it is not concerned with the creation of objects.

However, the code can be refactored to use the Factory method and better communicate the intent:

class CraneInterface(ABC):

    def __init__(self):
        self.__axis = self._make_axis()

    @property
    def axis(self) -> AxisInterface:
        return self.__axis

    @abstractmethod
    def _make_axis(self) -> AxisInterface:
        """
        Factory method: "Subclasses override to change the class of object that will be created"
        """
        pass

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.