¿Cuál es el formato de encabezado común de los archivos Python?


Me encontré con el siguiente formato de encabezado para los archivos fuente de Python en un documento sobre las directrices de codificación de Python:

#!/usr/bin/env python

"""Foobar.py: Description of what foobar does."""

__author__      = "Barack Obama"
__copyright__   = "Copyright 2009, Planet Earth"

¿Es este el formato estándar de las cabeceras en el mundo Python? ¿Qué otros campos / información puedo poner en el encabezado? Los gurús de Python comparten sus pautas para un buen código fuente de Python: -)

Author: Martin Thoma, 2009-10-06

4 answers

Son todos los metadatos para el módulo Foobar.

El primero es el docstring del módulo, que ya se explica en La respuesta de Pedro.

¿Cómo organizo mis módulos (archivos fuente)? (Archivo)

La primera línea de cada archivo debe ser #!/usr/bin/env python. Esto hace posible ejecutar el archivo como un script que invoca al intérprete implícitamente, por ejemplo, en un contexto CGI.

Siguiente debe ser el docstring con un descripci. Si la descripción es larga, la primera línea debe ser un breve resumen que tenga sentido por sí solo, separado del resto por una nueva línea.

Todo el código, incluidas las instrucciones de importación, debe seguir el docstring. De lo contrario, el docstring no será reconocido por el intérprete, y no tendrá acceso a él en sesiones interactivas (es decir, a través de obj.__doc__) o al generar documentación con herramientas automatizadas.

Importar módulos incorporados primero, seguido de módulos de terceros, seguido de cualquier cambio en la ruta y sus propios módulos. Especialmente, es probable que las adiciones a la ruta y los nombres de sus módulos cambien rápidamente: mantenerlos en un solo lugar los hace más fáciles de encontrar.

Lo siguiente debe ser la información de autoría. Esta información debe seguir este formato:

__author__ = "Rob Knight, Gavin Huttley, and Peter Maxwell"
__copyright__ = "Copyright 2007, The Cogent Project"
__credits__ = ["Rob Knight", "Peter Maxwell", "Gavin Huttley",
                    "Matthew Wakefield"]
__license__ = "GPL"
__version__ = "1.0.1"
__maintainer__ = "Rob Knight"
__email__ = "[email protected]"
__status__ = "Production"

El estado debería ser típicamente uno de "Prototipo", "Desarrollo" o "Producción". __maintainer__ debe ser el persona que corregirá errores y hará mejoras si se importa. __credits__ difiere de __author__ en que __credits__ incluye personas que reportaron correcciones de errores, hicieron sugerencias, etc. pero en realidad no escribió el código.

Aquí tiene más información, listado de __author__, __authors__, __contact__, __copyright__, __license__, __deprecated__, __date__ y __version__ como se reconoce metadatos.

 465
Author: Esteban Küber,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:34:30

Estoy fuertemente a favor de los encabezados de archivo mínimos, con lo que quiero decir solo:

  • La línea hashbang (#!) si se trata de un script ejecutable
  • Módulo docstring
  • Importaciones, agrupadas como se describe en voyager's respuesta.

Todo lo demás es una pérdida de tiempo, espacio visual, y es activamente engañoso.

Si tiene renuncias legales o información de licencia, va a un archivo separado. No necesita infectar todos los archivos de código fuente. Sus derechos de autor debería ser parte de esto. La gente debería poder encontrarlo en su archivo LICENSE, no en el código fuente aleatorio.

Los metadatos, como la autoría y las fechas, ya están mantenidos por su control de código fuente. No es necesario agregar una versión menos detallada, errónea y desactualizada de la misma información en el propio archivo.

No creo que haya ningún otro dato que todo el mundo necesite poner en todos sus archivos fuente. Usted puede tener algún requisito particular para hacerlo, pero tales cosas se aplican, por definición, solo para ti. No tienen lugar en "encabezados generales recomendados para todos".

 126
Author: Jonathan Hartley,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-04-04 14:42:09

También ver PEP 263 si está utilizando un conjunto de caracteres no ascii

Resumen

Este PEP propone introducir una sintaxis para declarar la codificación de un archivo fuente de Python. La información de codificación es utilizada por el Python parser para interpretar el archivo usando la codificación dada. Mas notablemente, esto mejora la interpretación de los literales Unicode en el código fuente y permite escribir literales Unicode usando, por ejemplo, UTF-8 directamente en un editor compatible con Unicode.

Problema

En Python 2.1, los literales Unicode solo se pueden escribir usando el Latin-1 based encoding "unicode-escape". Esto hace que el entorno de programación bastante hostil para los usuarios de Python que viven y trabajar en lugares no latinos-1 como muchos de los asiáticos pais. Los programadores pueden escribir sus cadenas de 8 bits utilizando el codificación favorita, pero están vinculados a la codificación" unicode-escape" para Unicode literal.

Solución propuesta

Propongo que la codificación del código fuente de Python sea visible y se puede cambiar por archivo fuente mediante el uso de un comentario especial en la parte superior del archivo para declarar la codificación.

Para hacer que Python sea consciente de esta declaración de codificación, un número de los cambios de concepto son necesarios con respecto al manejo de Datos del código fuente de Python.

Definiendo la codificación

Python por defecto a ASCII como codificación estándar si no hay otro se dan sugerencias de codificación.

Para definir una codificación de código fuente, un comentario mágico debe ser colocado en los archivos de origen ya sea como primero o segundo línea en el archivo, como:

      # coding=<encoding name>

O (usando formatos reconocidos por editores populares)

      #!/usr/bin/python
      # -*- coding: <encoding name> -*-

O

      #!/usr/bin/python
      # vim: set fileencoding=<encoding name> :

...

 18
Author: John La Rooy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-06-18 02:06:55

Las respuestas anteriores son realmente completas, pero si quieres un encabezado rápido y sucio para copiar y pegar, usa esto:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""Module documentation goes here
   and here
   and ...
"""

Por qué esto es bueno:

  • La primera línea es para usuarios *nix. Elegirá el intérprete de Python en la ruta del usuario, por lo que elegirá automáticamente el intérprete preferido por el usuario.
  • El segundo es la codificación del archivo. Hoy en día cada archivo debe tener una codificación asociada. UTF-8 funcionará en todas partes. Solo los proyectos heredados usarían otros codificación.
  • Y una documentación muy sencilla. Puede llenar varias líneas.

Véase también: https://www.python.org/dev/peps/pep-0263 /

Si solo escribes una clase en cada archivo, ni siquiera necesitas la documentación (iría dentro de la clase doc).

 14
Author: neves,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-04 14:13:50