python - indent - Estilo de codificación(PEP8)-Nivel de módulo "Dunders"

format code intellij

Question

Definición de "Dunder" (Duble bajo puntuación): http://www.urbandictionary.com/define.php?term=Dunder

Tengo una pregunta según la ubicación del nivel de módulo "dunders" (como __all__ , __version__ , __author__ etc.) en el código Python.

La pregunta se me ocurrió mientras leía PEP8 y veía this pregunta de desbordamiento de pila.

La respuesta aceptada dice:

__author__ es una "variable" global y, por lo tanto, debe aparecer debajo de las importaciones.

Pero en la sección PEP8, a nivel de Módulo nombres de Dunder, leí lo siguiente:

Los "dunders" del nivel del módulo (es decir, los nombres con dos guiones bajos __all__ y dos finales) como __all__ , __author__ , __version__ , etc. deben colocarse después de la cadena de documentación del módulo pero antes de cualquier declaración de importación, excepto de __future__ import. Python ordena que las futuras importaciones deben aparecer en el módulo antes de cualquier otro código, excepto docstrings.

Los autores también dan un ejemplo de código:

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

Pero cuando pongo lo anterior en PyCharm, veo esta advertencia (también veo la captura de pantalla):

PEP8: la importación a nivel de módulo no está en la parte superior del archivo

Pregunta: ¿Cuál es la manera / el lugar correctos para almacenar estas variables con dos guiones bajos?

Answer 1

PEP 8 recientemente se actualizó para colocar la ubicación antes de las importaciones. Ver la revisión cf8e888b9555 , comprometida el 7 de junio de 2016:

Relax __all__ ubicación.

Ponga todos los dunders de nivel de módulo juntos en la misma ubicación y elimine la información de contabilidad redundante de la versión.

Cierra # 27187. Parche de Ian Lee.

El texto se actualizó aún más al día siguiente para abordar el tema from __future__ import ... caveat.

El parche se vincula con el problema # 27187 , que a su vez hace referencia a este problema de pycodestyle , donde se descubrió que el PEP 8 no estaba claro.

Antes de este cambio, ya que no había una guía clara sobre los dund globulares a nivel de módulo, PyCharm y la otra respuesta eran correctas en ese momento . No estoy seguro de cómo PyCharm implementa sus controles PEP 8; si usan el proyecto pycodestyle (el comprobador de estilo de Python), estoy seguro de que se solucionará automáticamente. De lo contrario, tal vez presentar un error con ellos para ver esto corregido.