28

What is the convention for naming interfaces and abstract classes in Python? PEP 8 doesn't discuss this. For example, in Java, interfaces are often named with an I prefix. In PHP (prior to namespaces), abstract classes are typically named with an _Abstract suffix.

(I realize that Pythonists are not keen on interfaces, and perhaps this is the reason why I can't find much consensus on this topic. But the usage of interfaces and abstract classes is not my question.)

Neuron
  • 5,141
  • 5
  • 38
  • 59
Mark E. Haase
  • 25,965
  • 11
  • 66
  • 72
  • They are the same as typical classes. As far as I am aware of, there aren't any additional rules to it. – Tyler Crompton May 23 '12 at 16:11
  • I've been programming in Python since 2.2, and I have not seen any widely used conventions for either of these. – NPE May 23 '12 at 16:13
  • Possible duplicate: http://stackoverflow.com/questions/7809287/python-naming-conventions-for-attributes-and-methods-meant-to-be-overwritten – Hannele May 23 '12 at 16:13
  • I use I for interface like c++: IPerson, and Abstract suffix: PersonAbstract – pylover May 23 '12 at 16:25

4 Answers4

14

I'm not aware of any community-wide standards in that regard apart from PEP8, which doesn't address this specifically.

I'd suggest to do whatever your team is most comfortable with, but above all else be consistent.

wizulus
  • 5,653
  • 2
  • 23
  • 40
Daenyth
  • 35,856
  • 13
  • 85
  • 124
  • Protocols were introduced long ago after PEP8, how this information would even be there? Or you want to say that old PEPs are sometimes updated ? – validname May 06 '22 at 11:37
13

I think naming an interface with an I prefix is perfectly acceptable.

e.g.:

  • IFoo
  • IPublishable

A few years back I used Zope Interfaces. I noticed most codebases used this convention. Our team did too.

We preferred IFoo vs. FooInterface or IFooInterface

Neuron
  • 5,141
  • 5
  • 38
  • 59
Shekhar
  • 7,095
  • 4
  • 40
  • 45
12

I would look towards the number tower (from numbers), the collection ABCs (from collections.abc), or the other core ABCs (such as importlib.abc) for the most "Pythonic" way to do this.

The consensus from this is to just name them as-is, and let human understanding recognize them as abstract.

AstraLuma
  • 609
  • 5
  • 16
  • 5
    Older python libraries didn't follow PEP8. Looking at newer libraries like asyncio one sees classes like AbstractEventLoop, BaseProtocol (Common base class for protocol interfaces), Protocol (Interface for stream protocol). So no 'I' prefix. – Scott P. Nov 20 '19 at 16:51
9

TL;DR

If you don't care about type hints, name them whatever you like. Otherwise, ABCs are your API for other developers. Their names should be clean without any clutter. The concrete implementation should tell you why it is special.

Call your abstract class User and the implementing classes ServerUser and LocalUser

Why would we need such a convention in the first place?

The first one should ask themselves is, why would we care about naming of classes?

In statically typed languages (which python is not), the names of your Interfaces represent an API through which other developers interact with your code. So the caller of a function should quickly understand the meaning of parameters and return types. An example from Java (where prefixing Interfaces has fallen out of fashion some time ago..) would be:

public void signupUsers(Collection<User> users) {
    // TODO: do something with users
}

Here we want the name to be as pure as possible. We accept any Collection and any User. It might be an ArrayList, HashSet, LocalUser or a ServerUser, we don't care.

Why is there no such standard in Python?

This was not relevant in python, since it is a dynamically typed language. In the following code, you don't care how the classes are called:

def signup_users(users):
    pass  # TODO: do something with users

The name would have only been relevant when creating a class and checking its type, which are not common enough to justify a full blown naming convention

Why would someone care about naming of classes in Python nowadays?

But things are changing, because of the introduction of the typing module. You can now explicitly state types. If we want to embrace this new feature, we should consider the naming of our classes.

So what names should our classes get?

By the same logic as to why other languages are ditching the prefixes for interfaces, I believe ABCs (if they play a similar role to interfaces) should have a clean name. A name like User is much nicer to read than IUser. If you have a concrete implementation of your user, the name of that implementation should tell you what is special about it. Is it a user which data is updated with data from a server? Call it ServerUser. Do you store the user data locally? Call it LocalUser.

def signup_users(users: Iterable[User]) -> None:
    pass  # TODO: do something with users

The "ugly" code which cares about the implementation details would look like this:

lovelace = LocalUser("Aida", "Lovelace", 1815)
babbage = ServerUser("htts://some_service.com/users/charles_babbage")
signup_users([aida, babbage])

This puts the burden of dealing with convoluted names on the caller who has to deal with the implementation - as it should

Neuron
  • 5,141
  • 5
  • 38
  • 59