18

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 Stack Overflow 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.

The authors also give a 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 above into PyCharm, I see this warning (also see the screenshot):

PEP8: module level import not at top of file

PyCharm ignoring PEP8?

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

Community
  • 1
  • 1
linusg
  • 5,719
  • 4
  • 24
  • 68

1 Answers1

20

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.

Martijn Pieters
  • 889,049
  • 245
  • 3,507
  • 2,997
  • Wow, so fast and clear. Will accept this answer in nine (why so long?) minutes :) Will anybody notice this change and update the PEP8 checker behaviour in the next time? – linusg Aug 19 '16 at 17:09
  • @linusg: the issue was raised by the pycodestyle project, so I'm sure that'll be updated. File a bug with PyCharm if you want it fixed there. – Martijn Pieters Aug 19 '16 at 17:10
  • I'll do some more research in the next days to find out how PEP8 checks are done in PyCharm, and eventually file a bug. I'll edit my question then. – linusg Aug 20 '16 at 12:12
  • 1
    @AXO: that's just a dupe of https://github.com/PyCQA/pycodestyle/issues/394 – Martijn Pieters Jan 22 '17 at 15:39