Coding style (PEP8) - Module level "dunders"
Asked Answered
R

1

22

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?

Rickets answered 19/8, 2016 at 17:1 Comment(2)
PEP 8 is a living document. Take into account that it could have been silent on the subject before.Lexy
@MartijnPieters - Any chance to see when a section was added/changed?Rickets
L
28

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.

Lexy answered 19/8, 2016 at 17:6 Comment(4)
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?Rickets
@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.Lexy
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.Rickets
@AXO: that's just a dupe of github.com/PyCQA/pycodestyle/issues/394Lexy

© 2022 - 2024 — McMap. All rights reserved.