The Question :
534 people think this question is useful
I came across the following header format for Python source files in a document about Python coding guidelines:
"""Foobar.py: Description of what foobar does."""
__author__ = "Barack Obama"
__copyright__ = "Copyright 2009, Planet Earth"
Is this the standard format of headers in the Python world?
What other fields/information can I put in the header?
Python gurus share your guidelines for good Python source headers 🙂
The Question Comments :
The Answer 1
605 people think this answer is useful
Its all metadata for the
The first one is the
docstring of the module, that is already explained in Peter’s answer.
The first line of each file shoud be
#!/usr/bin/env python. This makes it possible to run the file as a script invoking the interpreter implicitly, e.g. in a CGI context.
Next should be the docstring with a description. If the description is long, the first line should be a short summary that makes sense on its own, separated from the rest by a newline.
All code, including import statements, should follow the docstring. Otherwise, the docstring will not be recognized by the interpreter, and you will not have access to it in interactive sessions (i.e. through
obj.__doc__) or when generating documentation with automated tools.
Import built-in modules first, followed by third-party modules, followed by any changes to the path and your own modules. Especially, additions to the path and names of your modules are likely to change rapidly: keeping them in one place makes them easier to find.
Next should be authorship information. This information should follow this format:
__author__ = "Rob Knight, Gavin Huttley, and Peter Maxwell"
__copyright__ = "Copyright 2007, The Cogent Project"
__credits__ = ["Rob Knight", "Peter Maxwell", "Gavin Huttley",
__license__ = "GPL"
__version__ = "1.0.1"
__maintainer__ = "Rob Knight"
__email__ = "email@example.com"
__status__ = "Production"
Status should typically be one of “Prototype”, “Development”, or “Production”.
__maintainer__ should be the person who will fix bugs and make improvements if imported.
__credits__ differs from
__author__ in that
__credits__ includes people who reported bug fixes, made suggestions, etc. but did not actually write the code.
Here you have more information, listing
__version__ as recognized metadata.
The Answer 2
189 people think this answer is useful
I strongly favour minimal file headers, by which I mean just:
- The hashbang (
#! line) if this is an executable script
- Module docstring
- Imports, grouped in the standard way, eg:
import os # standard library
import requests # 3rd party packages
from mypackage import ( # local source
ie. three groups of imports, with a single blank line between them. Within each group, imports are sorted. The final group, imports from local source, can either be absolute imports as shown, or explicit relative imports.
Everything else is a waste of time, visual space, and is actively misleading.
If you have legal disclaimers or licencing info, it goes into a separate file. It does not need to infect every source code file. Your copyright should be part of this. People should be able to find it in your
LICENSE file, not random source code.
Metadata such as authorship and dates is already maintained by your source control. There is no need to add a less-detailed, erroneous, and out-of-date version of the same info in the file itself.
I don’t believe there is any other data that everyone needs to put into all their source files. You may have some particular requirement to do so, but such things apply, by definition, only to you. They have no place in “general headers recommended for everyone”.
The Answer 3
38 people think this answer is useful
The answers above are really complete, but if you want a quick and dirty header to copy’n paste, use this:
# -*- coding: utf-8 -*-
"""Module documentation goes here
Why this is a good one:
- The first line is for *nix users. It will choose the Python interpreter in the user path, so will automatically choose the user preferred interpreter.
- The second one is the file encoding. Nowadays every file must have a encoding associated. UTF-8 will work everywhere. Just legacy projects would use other encoding.
- And a very simple documentation. It can fill multiple lines.
See also: https://www.python.org/dev/peps/pep-0263/
If you just write a class in each file, you don’t even need the documentation (it would go inside the class doc).
The Answer 4
24 people think this answer is useful
Also see PEP 263 if you are using a non-ascii characterset
This PEP proposes to introduce a syntax to declare the encoding of
a Python source file. The encoding information is then used by the
Python parser to interpret the file using the given encoding. Most
notably this enhances the interpretation of Unicode literals in
the source code and makes it possible to write Unicode literals
using e.g. UTF-8 directly in an Unicode aware editor.
In Python 2.1, Unicode literals can only be written using the
Latin-1 based encoding “unicode-escape”. This makes the
programming environment rather unfriendly to Python users who live
and work in non-Latin-1 locales such as many of the Asian
countries. Programmers can write their 8-bit strings using the
favorite encoding, but are bound to the “unicode-escape” encoding
for Unicode literals.
I propose to make the Python source code encoding both visible and
changeable on a per-source file basis by using a special comment
at the top of the file to declare the encoding.
To make Python aware of this encoding declaration a number of
concept changes are necessary with respect to the handling of
Python source code data.
Defining the Encoding
Python will default to ASCII as standard encoding if no other
encoding hints are given.
To define a source code encoding, a magic comment must
be placed into the source files either as first or second
line in the file, such as:
# coding=<encoding name>
or (using formats recognized by popular editors)
# -*- coding: <encoding name> -*-
# vim: set fileencoding=<encoding name> :