linusg linusg - 3 months ago 32
Python Question

Coding style (PEP8) - Module level "dunders"

Definition of "Dunder" (Double underscore): http://www.urbandictionary.com/define.php?term=Dunder




I have a question according the placement of module level "dunders" (like
__all__
,
__version__
,
__author__
etc.) in Python code.

The question came up to me while reading through PEP8 and seeing this SO question.

The accepted answer says:


__author__
is a global "variable" and should therefore appear below the imports.


But in the PEP8 section Module level dunder names I read the following:


Module level "dunders" (i.e. names with two leading and two trailing
underscores) such as
__all__
,
__author__
,
__version__
, etc. should
be placed after the module docstring but before any import statements
except from
__future__
imports. Python mandates that future-imports
must appear in the module before any other code except docstrings.


They also give an code example:

"""This is the example module.

This module does stuff.
"""

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']
__version__ = '0.1'
__author__ = 'Cardinal Biggles'

import os
import sys


But when I put the following into PyCharm, I see this warning:


PEP8: module level import not at top of file


Pycharm ignoring PEP8?

Question: What is the correct way to store these variables with double underscores?

Answer

PEP 8 recently was updated to put the location before the imports. See revision cf8e888b9555, committed on June 7th, 2016:

Relax __all__ location.

Put all module level dunders together in the same location, and remove the redundant version bookkeeping information.

Closes #27187. Patch by Ian Lee.

The text was further updated the next day to address the from __future__ import ... caveat.

The patch links to issue #27187, which in turn references this pycodestyle issue, where it was discovered PEP 8 was unclear.

Before this change, as there was no clear guideline on module-level dunder globals, so PyCharm and the other answer were correct at the time. I'm not sure how PyCharm implements their PEP 8 checks; if they use the pycodestyle project (the defacto Python style checker), then I'm sure it'll be fixed automatically. Otherwise, perhaps file a bug with them to see this fixed.

Comments