¿Cómo escribir código Pythonico?

Cami Gomez - Python Developer

 Temas
● PEP
○ PEP 0
○ PEP 1
○ PEP 8

● Linters
○ Pylint
○ Flake8
● Formatters
○ Black
○ autopep8
● pre-commits
¡Vamos a Jugar!

https://kahoot.it/
PEP
¿Qué es PEP?
Python Enhancement Proposal (Propuesta de mejora de Python )

Un PEP es un documento que describe nuevas características

propuestas para Python y documenta aspectos de Python, como
diseño y estilo, para la comunidad.
PEP 0
 PEP 0 - Index of Python Enhancement Proposals
Este PEP contiene el índice de todas las propuestas de mejora de
Python, conocidas como PEP. Los números de PEP son asignados
por los editores de PEP y, una vez asignados, nunca se modifican. El
historial de control de versiones de los textos del PEP representa su
registro histórico.

https://peps.python.org/pep-0000/
 PEP Types
● I — Informational: PEP no normativo que contiene antecedentes, pautas
u otra información relevante para el ecosistema de Python.

● P — Process: PEP normativo que describe o propone un cambio en un

proceso, flujo de trabajo o gobernanza de la comunidad de Python.

● S — Standards Track: PEP normativo con una nueva función para Python,
cambio de implementación para CPython o estándar de
interoperabilidad para el ecosistema
 PEP status
Código Estado Descripción

A Accepted Propuesta normativa aceptada para su implementación.

A Active Orientación informativa actualmente válida, o un proceso en uso.

D Deferred Borrador inactivo que puede ser retomado en un momento posterior.

<No letter> Draft Propuesta en discusión activa y revisión.

F Final Aceptado e implementación completa, o ya no está activo.

P Provisional Aceptado provisionalmente pero se necesitan comentarios adicionales.

R Rejected Rechazada formalmente y no será aceptada.

S Superseded Reemplazada por otra PEP sucesora.

W Withdrawn Eliminado de consideración por el patrocinador o los autores.

PEP 1
 PEP 1 - PEP Purpose and Guidelines
Es un documento que nos explica que es un PEP, los elementos que
lo conforman, la nomenclatura utilizada y el flujo que se tiene al
proponer nuevos PEPs.

https://peps.python.org/pep-0001/
PEP 8
 PEP 8 – Style Guide for Python Code
PEP8 es un documento que proporciona pautas y mejores prácticas
sobre cómo escribir código Python. Fue escrito en 2001 por Guido
van Rossum, Barry Varsovia y Nick Coghlan.

El enfoque principal de PEP 8 es mejorar la legibilidad y la

consistencia del código de Python.

https://peps.python.org/pep-0008/
“Code is read much more often
than it is written.”
— Guido van Rossum
 PEP 20 – The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than «right now».
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

https://peps.python.org/pep-0020/
 PEP 8
● Naming Conventions
● Code Layout
● Indentation
● Comments
● Whitespace in Expressions and Statements

https://realpython.com/python-pep8/
Naming Conventions

“Explicit is better than implicit.”

— The Zen of Python

 Naming Styles
Type Naming Convention Examples

Function Use una palabra o palabras en minúsculas. function, my_function

Separe las palabras con guiones bajos para mejorar la legibilidad.

Variable Use una sola letra, palabra o palabras en minúsculas. x, var, my_variable
Separe las palabras con guiones bajos para mejorar la legibilidad.

Class Comienza cada palabra con una letra mayúscula. No separe las palabras Model, MyClass
con guiones bajos. Este estilo se llama camel case o pascal case.

Method Use una palabra o palabras en minúsculas. class_method, method

Separe las palabras con guiones bajos para mejorar la legibilidad.

Constant Use una sola letra, palabra o palabras en mayúsculas. CONSTANT, MY_CONSTANT,
Separe las palabras con guiones bajos para mejorar la legibilidad. MY_LONG_CONSTANT

Module Use una palabra o palabras cortas en minúsculas. module.py,

Separe las palabras con guiones bajos para mejorar la legibilidad. my_module.py

Package Use una palabra o palabras cortas en minúsculas. package, mypackage

No separe las palabras con guiones bajos.
¿Cómo seleccionar nombres?
Elegir nombres para sus variables, funciones, clases, etc. puede ser un desafío.
Debe pensar bastante en sus opciones de nombres al escribir código, ya que hará
que su código sea más legible.

La mejor manera de nombrar sus objetos en Python es usar nombres descriptivos

para dejar claro lo que representa el objeto.
Code Layout
“Beautiful is better than ugly.”

— The Zen of Python

Blank Lines
Los espacios en blanco verticales, o líneas en blanco, pueden mejorar
en gran medida la legibilidad de su código.

● Rodee las funciones y clases de nivel superior con dos líneas en

blanco.
● Rodee las definiciones de métodos dentro de las clases con una
sola línea en blanco.
● Use líneas en blanco con moderación dentro de las funciones para
mostrar pasos claros.
Maximum Line Length and Line Breaking
PEP 8 sugiere que las líneas deben limitarse a 79 caracteres. Esto se
debe a que le permite tener varios archivos abiertos uno al lado del
otro, al tiempo que evita el ajuste de línea.
Indentation
“There should be one—and preferably
only one—obvious way to do it.”

— The Zen of Python

Indentation
La sangría, o espacio en blanco inicial, es extremadamente importante
en Python. El nivel de sangría de las líneas de código en Python
determina cómo se agrupan las declaraciones.
Las reglas de sangría clave establecidas por PEP 8 son las siguientes:

● Use 4 espacios consecutivos para indicar sangría.

● Prefiere los espacios a los tabs.
Tabs vs. Spaces
Como se mencionó anteriormente, debe usar espacios en lugar de
tabulaciones al sangrar el código. Puede ajustar la configuración en su
editor de texto para generar 4 espacios en lugar de un carácter de
tabulación, cuando presiona la tecla Tabulador.
Sangría después de saltos de línea
Cuando usa continuaciones de línea para mantener las líneas en
menos de 79 caracteres, es útil usar sangría para mejorar la legibilidad.

Permite al lector distinguir entre dos líneas de código y una sola línea de
código que abarca dos líneas.
Dónde poner los cierres
Las continuaciones de línea le permiten romper líneas dentro de
paréntesis, corchetes o llaves.

Es fácil olvidarse de la llave de cierre, pero es importante colocarla en

un lugar sensato. De lo contrario, puede confundir al lector.
Comments
“If the implementation is hard to
explain, it’s a bad idea.”

— The Zen of Python

Block Comments
Use comentarios de bloque para documentar una pequeña sección de
código.
Son útiles cuando tienes que escribir varias líneas de código para
realizar una sola acción, como importar datos de un archivo o
actualizar una entrada de la base de datos.
Son importantes porque ayudan a otros a comprender el propósito y la
funcionalidad de un bloque de código determinado.
Inline Comments
Los comentarios en línea explican una sola declaración en una pieza de
código. Son útiles para recordar, o explicar a otros, por qué es necesaria
cierta línea de código.
● Utilice los Inline Comments con moderación.
● Escriba Inline Comments en la misma línea que la declaración a la que
se refieren.
● Separe los comentarios en línea con dos o más espacios de la
declaración.
● Comience los Inline Comments con un # y un solo espacio, como
comentarios de bloque.
● No los uses para explicar lo obvio.
Documentation Strings
Los Documentation Strings, o docstrings, son cadenas entre comillas dobles (""") o simples
(''') que aparecen en la primera línea de cualquier función, clase, método o módulo. Puede
usarlas para explicar y documentar un bloque específico de código Hay un PEP completo,
PEP 257, que cubre cadenas de documentos.

Las reglas más importantes que se aplican a las cadenas de documentación son las
siguientes:

● Rodee las cadenas de documentación con tres comillas dobles a cada lado, como
en """Este es un Documentation Strings""".
● Escríbalos para todos los módulos, funciones, clases y métodos públicos.
● Ponga el """ que finaliza una cadena de documentación multilínea en una sola línea.
● Para cadenas de documentos de una línea, mantenga el """ en la misma línea.
Whitespace in Expressions
and Statements
“Sparse is better than dense.”

— The Zen of Python

Espacios en blanco alrededor de los
operadores binarios
Rodee los siguientes operadores binarios con un solo espacio a cada
lado:

● Operadores de asignación (=, +=, -=, etc.)

● Comparaciones (==, !=, >, <. >=, <=) y (is, is not, in, not in)
● Booleanos (and, not, or)
Cuándo evitar agregar espacios en blanco
La siguiente lista describe algunos casos en los que debe evitar agregar
espacios en blanco:

● Inmediatamente dentro de paréntesis, corchetes o llaves

● Antes de una coma, punto y coma o dos puntos
● Antes del paréntesis abierto que inicia la lista de argumentos de
una llamada de función
● Antes del paréntesis abierto que inicia un índice o segmento
● Entre una coma final y un paréntesis de cierre
● Para alinear operadores de asignación
Recomendaciones adicionales.
“Simple is better than complex.”

— The Zen of Python

Recomendaciones adicionales.
● No compare valores booleanos con True o False usando el operador de
equivalencia.
● Utilice el hecho de que las secuencias vacías son falsas en
declaraciones if.
● Use is not preferiblemente sobre not ... is en declaraciones if.
● No use if x: cuando quiere decir if x is not None:
● Use .startswith() y .endswith() en lugar de usar recortar la palabra.
Nota: Cuando ignorar PEP 8
La respuesta corta a esta pregunta es nunca. Sin embargo, algunas
pautas en PEP8 son inconvenientes en los siguientes casos:

● Si cumplir con PEP 8 rompería la compatibilidad con el software

existente
● Si el código que rodea lo que está trabajando es inconsistente
con PEP 8
● Si el código debe seguir siendo compatible con versiones
anteriores de Python
Linters
Linters
Los linters son programas que analizan el código y marcan los
errores. Proporcionan sugerencias sobre cómo corregir el error.

Los linters son particularmente útiles cuando se instalan como

extensiones de su editor de texto, ya que señalan errores y
problemas de estilo mientras escribe.

Algunos linters comunes son:

● Pylint
● Flake8
Instalación

pip install flake8

pip install pylint

formatters
Formatters
Un formatter en programación es una herramienta o programa que
se utiliza para formatear automáticamente el código fuente según
un conjunto de reglas o convenciones establecidas. Su propósito
principal es ajustar la estructura y estilo del código de manera
consistente, lo que facilita su lectura, comprensión y mantenimiento.

Algunos formatters comunes son:

● autopep8
● black
Instalación

pip install autopep8

pip install black

Pre-commits

https://pre-commit.com/
Pre-commits
Un pre-commit (pre-commit hook) es una función o script que se
ejecuta automáticamente antes de confirmar (commit) los
cambios en un sistema de control de versiones, como Git. Su
propósito es realizar diversas comprobaciones o acciones en los
archivos modificados antes de que se registren en el repositorio.
Instalación

pip install pre-commit

Ejercicio práctico
 Ejercicio práctico
https://github.com/camigomezdev/dojo_pep8