You don't need to raise NotImplementedError for abstract methods

[Xophmeister]

Documentation

In the documentation for NotImplementedError, we see the following:

cpython/Doc/library/exceptions.rst

Lines 299 to 304 in a7715cc

	.. exception:: NotImplementedError
	This exception is derived from :exc:`RuntimeError`. In user defined base
	classes, abstract methods should raise this exception when they require
	derived classes to override the method, or while the class is being
	developed to indicate that the real implementation still needs to be added.

If "abstract base classes" are meant to mean ABCs from the standard library, this is unnecessary as the ABC metaclass will prohibit instantiation of any derived class that doesn't implement an abstract method. Indeed, adding a raise would be dead code that would flaunt, say, coverage metrics.

[stevendaprano]

I think the purpose of raising NotImplementedError is to protect against calling the abstract method from the class like this:

>>> from abc import ABC, abstractmethod
>>> 
>>> class Animal(ABC):
...     @abstractmethod
...     def move(self):
...         raise NotImplementedError
... 
>>> class Human(Animal):
...     def move(self):
...         print("human move")
... 
>>> Animal.move(Human())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in move
NotImplementedError

If we removed the NotImplementedError, calling the abstract move method would silently do nothing.

I think the statement should stay, or even be made more prominent in the docs. I see lots of abstract methods which wrongly (in my opinion) just have pass as the body.

Does anyone know whether linters check for this?

[sobolevn]

I cannoy say for all linters, but mypy does not catch it.

[cameron-simpson]

(a) I think NotImplementedError predates ABC and abstractmethod.
(b) you can implement a "abstract" class semanticly without ABC, and if you do then NotImplementedError is that way to ensure that your abstract method is meaningfully unworkable

It probably would be sensible to clarify the distinction between this mechanism (NotImplementedError) which would fire at runtime and the ABC metaclass mechanism which fires at class definition time.

But it's still reasonable to have an abstractmethod's code be raise NotImplementedError to make the situation really clear, not to mention aiding a linter unaware of abstractmethod specificly, but aware of unconditional raise results.

[Xophmeister]

It's worth pointing out that the documentation for abc.abstractmethod doesn't mention using NotImplementedError and uses ellipses in its examples. It's therefore not surprising that this is what is usually seen in the wild:

cpython/Doc/library/abc.rst

Lines 165 to 237 in 84bc6a4

	.. decorator:: abstractmethod
	A decorator indicating abstract methods.
	Using this decorator requires that the class's metaclass is :class:`ABCMeta`
	or is derived from it. A class that has a metaclass derived from
	:class:`ABCMeta` cannot be instantiated unless all of its abstract methods
	and properties are overridden. The abstract methods can be called using any
	of the normal 'super' call mechanisms. :func:`abstractmethod` may be used
	to declare abstract methods for properties and descriptors.
	Dynamically adding abstract methods to a class, or attempting to modify the
	abstraction status of a method or class once it is created, are only
	supported using the :func:`update_abstractmethods` function. The
	:func:`abstractmethod` only affects subclasses derived using regular
	inheritance; "virtual subclasses" registered with the ABC's :meth:`register`
	method are not affected.
	When :func:`abstractmethod` is applied in combination with other method
	descriptors, it should be applied as the innermost decorator, as shown in
	the following usage examples::
	class C(ABC):
	@abstractmethod
	def my_abstract_method(self, arg1):
	...
	@classmethod
	@abstractmethod
	def my_abstract_classmethod(cls, arg2):
	...
	@staticmethod
	@abstractmethod
	def my_abstract_staticmethod(arg3):
	...
	@property
	@abstractmethod
	def my_abstract_property(self):
	...
	@my_abstract_property.setter
	@abstractmethod
	def my_abstract_property(self, val):
	...
	@abstractmethod
	def _get_x(self):
	...
	@abstractmethod
	def _set_x(self, val):
	...
	x = property(_get_x, _set_x)
	In order to correctly interoperate with the abstract base class machinery,
	the descriptor must identify itself as abstract using
	:attr:`__isabstractmethod__`. In general, this attribute should be ``True``
	if any of the methods used to compose the descriptor are abstract. For
	example, Python's built-in :class:`property` does the equivalent of::
	class Descriptor:
	...
	@property
	def __isabstractmethod__(self):
	return any(getattr(f, '__isabstractmethod__', False) for
	f in (self._fget, self._fset, self._fdel))
	.. note::
	Unlike Java abstract methods, these abstract
	methods may have an implementation. This implementation can be
	called via the :func:`super` mechanism from the class that
	overrides it. This could be useful as an end-point for a
	super-call in a framework that uses cooperative
	multiple-inheritance.

To add to the linter evidence: Pylint also doesn't catch this.

The valid reasons for raising here are thus:

1. If you are implementing a base class/abstract method manually, without ABC's help.
2. If you routinely call base class methods (not @classmethods) against instantiated objects. (i.e., Presumably in inheritance situations, when super doesn't cut it.)
3. For documentation/signalling purposes.