I like to raise a NotImplementedError for any method that I want to implement, but where I haven't gotten around to doing it yet. I might already have a partial implementation, but prepend it with raise NotImplementedError() because I don't like it yet. On the other hand, I also like to stick to conventions, because this will make it easier for other people to maintain my code, and conventions might exist for a good reason.

However Pythons documentation for NotImplementedError states:

This exception is derived from RuntimeError. In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method.

That is a much more specific, formal use case than the one I describe. Is it a good, conventional style to raise a NotImplementedError simply to indicate that this part of the API is a work in progress? If not, is there a different standardised way of indicating this?

  • What do you mean by "appropriate?" Mar 5, 2014 at 20:54
  • 1
    @RobertHarvey I suppose I mean conventional, following common usage. I have rephrased my question now.
    – gerrit
    Mar 5, 2014 at 20:57
  • 2
    We use C# here primarily, but that sort of exception throwing is idiomatic here, and I would expect elsewhere. Break early and break loudly is a good guideline for identifying potential issues quickly (read: inexpensively).
    – Telastyn
    Mar 5, 2014 at 20:57
  • Generally if I am creating a class I just put TODO comments in unimplemented methods until I get around to implementing the functionality. If the class were going to be released to production before that happened, I would consider throwing exceptions.
    – user22815
    Mar 5, 2014 at 21:15
  • 5
    For what it's worth, this is what Microsoft Visual Studio does by default when you use the IDE to "implement an interface." At Robert Harvey says, the result is well understood.
    – catfood
    Mar 5, 2014 at 21:28

3 Answers 3


It's worth noting that, while the Python documentation provides a use case (and probably the canonical one) for this exception, it doesn't specifically exclude its use in other scenarios.

I would consider it appropriate to raise a NotImplementedError exception if you haven't overridden a method in a base class yet (to satisfy the "interface").

A cursory check on Google suggests that people will understand what you mean if you use the exception in this fashion. There are no side effects or unintended consequences that I know of; the method will simply throw an exception if it is called, and it will throw an exception that is well-understood by everyone.

The documentation for Python 3 reflects this exact usage:

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. [Emphasis added]

  • 1
    +1, but I'd also add that for this kind of convention, a little documentation can go a long way. Like a one-line note in a dev wiki, repo readme, or style guideline -- something like that -- explaining what you use this exception for.
    – Ben Lee
    Mar 10, 2014 at 20:43

This will be understood, whether you do it or not should depend on local (team or company) conventions. Note that it makes less sense in the context of TDD as the TEST should be what determines that the method isn't implemented.

The short version is: use if you and your team consider it appropriate.

  • 5
    FWIW, Throwing the exception should be a good way to get the test to fail, if for some reason you need to force that behavior. (It'd be useful as part of a method-definition intellisense stub, for example.)
    – DougM
    Mar 5, 2014 at 21:48

It seems that NotImplementedError is usually being raised for Python feature developments itself, like the following:

def fromkeys(cls, iterable, v=None):
    # There is no equivalent method for counters because setting v=1
    # means that no element can have a count greater than one.
    raise NotImplementedError(
        'Counter.fromkeys() is undefined.  Use Counter(iterable) instead.')



This class method is not implemented for Counter objects.



Not the answer you're looking for? Browse other questions tagged or ask your own question.