The general rule when writing Python code is to follow PEP 8. The rules
given later in this document override what is said in PEP 8.

Be tolerant of code that doesn’t follow these conventions: our code base
has been evolving over years and doesn’t always match the current style
as we update these rules. Also, we want to reuse software written for
other projects that do not adhere to our rules.

Remember that PEP 8 explicitly allows breaking a rule in the interest of
keeping code consistent.

A reasonable goal is that code covered by the ZPL should follow these
conventions.

Python files should always contain the most current license comment at
the top followed by the module documentation string.

Here is the template:

################################################################################ Copyright (c) 2016 Zope Foundation and Contributors.# All Rights Reserved.## This software is subject to the provisions of the Zope Public License,# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS# FOR A PARTICULAR PURPOSE###############################################################################"""One-line summary goes here.Module documentation goes here."""

The naming of attributes as recommended by PEP 8 is controversial. PEP 8
prefers attribute_name over attributeName. Newer code tends to
prefer the use of underscores over camel case. However, Zope has been
built originally with the latter rule and a lot of code still use this
scheme.

Boolean-type attributes should always form a true-false-question,
typically using “has” or “is” as prefix. Example: is_required instead
of required.

Method names should always start with a verb that describes the action.

try blocks should cover as little code as possible. except
statements should match exceptions as specific as possible.

For example, if you are converting a value to an int, and you want
to catch conversion errors, you need only catch ValueError. Be sure
to do the minimum possible between your try: and exceptValueError: statements:

Interface names adhere to PEP 8’s naming of classes, except that they
are prefixed with a capital I, as in IMagicThing.

One function of interfaces is to document functionality, so be very
verbose with the documentation strings.

All public interfaces should go into a file called interfaces.py.
“Public” interfaces are those that you expect to be implemented more
than once. Interfaces that are likely to be implemented only once, like
IGlobalAdapterService, should live in the same module as their
implementation.