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

Quoting https://www.python.org/dev/peps/pep-0008/#package-and-module-names:

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

For classes:

Class names should normally use the CapWords convention.

And function and (local) variable names should be:

lowercase, with words separated by underscores as necessary to improve readability

See this answer for the difference between a module, class and package:

• A Python module is simply a Python source file, which can expose classes, functions and global variables.
• A Python package is simply a directory of Python module(s).

So PEP 8 tells you that:

• modules (filenames) should have short, all-lowercase names, and they can contain underscores;
• packages (directories) should have short, all-lowercase names, preferably without underscores;
• classes should use the CapWords convention.

PEP 8 tells that names should be short; this answer gives a good overview of what to take into account when creating variable names, which also apply to other names (for classes, packages, etc.):

• variable names are not full descriptors;
• put details in comments;
• too specific name might mean too specific code;
• keep short scopes for quick lookup;
• spend time thinking about readability.

To finish, a good overview of the naming conventions is given in the Google Python Style Guide.

See Python PEP 8: Function and Variable Names:

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.