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 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

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

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.