Óscar Ramírez Jiménez - Python a fondo

• Editores de la propuesta:son los editores que comienzan y dan forma a la propuesta.

El proceso general de una propuesta, de forma resumida, sería:

1. Se comienza con una idea,a poder ser lo más resumida y concreta posible, y se envía a los canales de la comunidad para ver si se rechazaría directamente por algún motivo (por ejemplo, que solamente afecta a una parte de los pythonistas o que ya está repetida). Los canales usuales son las listas de emails en python-list@python.orgo en python-ideas@python.org. Si la recepción es buena, se puede comenzar con el borrador de la PEP y continuar con el proceso.

2. Cuando una propuesta quiere ser enviada,debe tener un patrocinador (sponsor) , que idealmente debería ser un desarrollador del núcleo de Python, aunque no es un requisito indispensable. Se añaden todos los campos necesarios siguiendo la plantilla que se provee en la PEP-1 y se envía al repositorio de GitHub donde están todas las demás PEP con el número 9999. Este número indica que es una nueva PEP en proceso de creación.

3. Tras el envío de la propuesta se hacen varias revisioneshasta que se decide la resoluciónfinal. El nombre de la figura de BDFL-Delegated queda reflejado en la propuesta y, normalmente, se asigna un desarrollador que será el que desarrolle la propuesta durante el proceso, ya sea de forma voluntaria o por designación del consejo.

4. Los mantenimientoso futuras revisiones de las propuestas estándar no suelen realizarse, puesto que quedan claramente definidas una vez terminadas (se especifica también en qué punto han terminado). Las propuestas informacionales o de proceso, por el contrario, sí que pueden contener cambios durante el tiempo que se abordan, según la naturaleza de la propuesta.

El código de cualquier aplicación en cualquier lenguaje se lee muchas más veces de las que se escribe,por tanto, es importante tener claro cómo escribirlo, y será aún mejor si se pueden seguir unas reglas y una guía que todos los desarrolladores acepten, entiendan y compartan. Python tiene una propuesta específica donde se define la guía de estilo para los desarrolladores del lenguaje y por la que habría que guiarse si se pretende escribir código pythónico.

Esta guía es fácil de seguir y se encuentra totalmente documentada en la PEP-8 https://www.python.org/dev/peps/pep-0008/, por lo que se recomienda su lectura en profundidad, aunque en esta sección se verán muchos de los puntos más relevantes a tener en cuenta cuando se programa en Python.

La indentaciónen Python es uno de los pilares principales del lenguaje, dado que define los bloques lógicos de código y la lógica entre los mismos; un simple cambio de indentación podría cambiar drásticamente la lógica de un programa, por lo que hay que tenerlos muy en cuenta y seguir las normas que se establecen para desarrollar correctamente.

En la guía oficial se establece la preferencia de indentación: utilizar espacios es mejor que utilizar tabulaciones, especialmente 4 espacios, aunque pueden prevalecer las tabulaciones en proyectos que ya las usen como indentación principal. Cuando se utilizan tabulaciones, el tamaño que toma en la pantalla cada indentación puede variar considerablemente dependiendo del editor o del tipo de letra, mientras que si se usan espacios, las diferencias entre fuentes suelen ser más sutiles. Cabe destacar que en Python 2 se podían tener diferentes caracteres de indentación en el código de espacios y de tabuladores en el mismo fichero, pero en Python 3 esto eleva un error de sintaxis, por lo que se recomienda usar siempre el mismo tipo (a poder ser, 4 espacios).

La longitud de línea máxima es de 79 caracteres para el código y de 72 caracteres para los comentarios y la documentación. Esto favorece que los editores de texto con límite de ancho de línea de 80 caracteres muestren el código correctamente y sin necesidad de utilizar saltos de línea, ayudando también a poder abrir varios archivos en la misma ventana con facilidad.

Para equipos de desarrollo que realmente quieran utilizar una longitud mayor de línea y estén de acuerdo con aumentar el número de caracteres por línea, se permite llegar hasta un límite de 99 caracteres para el código, quedando el límite para comentarios y textos de documentación en el mismo que antes: 72 caracteres.

Cuando la longitud de una línea sea mayor que la cantidad máxima predefinida, se utilizará el carácter "\" para hacer un salto de línea y hacer que el texto continúe en la siguiente.

En Python se intenta tener solo el número mínimo necesario de espacios y líneas en blanco para permitir que el código se lea correctamente y de manera natural. Por tanto, es mejor evitar cualquier tipo de espacio añadido que parezca exagerado, como en los siguientes ejemplos.

Los saltos de línea se añaden antes que los operadores lógicos, dado que mejoran la legibilidad del código, y siempre deben estar alineados al mismo nivel, como en el siguiente ejemplo:

A la hora de añadir las líneas en blanco existen diferentes reglas:

• Las funciones generales o las clases deberán estar rodeadas de dos líneas en blanco.

• Los métodos definidos dentro de clases se rodean de solo una línea en blanco.

• Se pueden usar líneas en blanco de forma moderada entre bloques de funciones o entre secciones lógicas.

• Algunos editores de texto reconocen el control-L (^L) como separador de página, por tanto, puede ser usado para separar las partes de código.

• Para las comparaciones de si un objeto es verdadero o falso, comprobando si existe el primer elemento de una lista o la longitud de una cadena, se recomienda utilizar las herramientas del lenguaje.

• La forma correcta de comprobar si una variable tiene el valor de True, False o None, es con el operador is o is not, intentando evitar el uso de negaciones de expresiones afirmativas.

• La importación de módulos se hará siempre al comienzo del fichero.

• El orden de importación de los módulos es:

− Módulos de la librería estándar.

− Módulos de terceros (otras librerías).

− Módulos propios.

− Nota: dentro de cada sección se mantendrá el orden alfabético.

PEP-8 es bastante explícito a la hora de definir las reglas de cómo deberían ser los comentarios del código:

• Es mucho mejor no tener comentarios que tener comentarios que contradigan el código.