Clase#2.

Python Avanzado

¿Cómo escribir
código Pythonico?
Cami Gomez - Python Developer
Hola soy Cami
Soy desarrolladora Backend en Huge y
profesora de programación para niños.

Amo el mundo de la tecnología y compartir

conocimiento, es mi pequeña forma de
contribuir a cambiar el mundo.

También pueden hablar conmigo sobre

gatos, viajes, juegos de mesa y buceo.
 Tabla de contenido
Clase #2

/01 PEP /02 Linters

Qué es PEP y cómo
potencia mi código. Pylint, Flake8
PEP 0, PEP1, PEP 8, PEP20

/03 Formatters /04 Pre-commits

Black, autopep8
¿Cuál es la forma correcta
de nombrar una función
en Python?

Snake Case
 ¿Cuál es la forma
correcta de nombrar una
constante en Python?

Completamente en Mayúscula
 Según la guía de estilos
de Python, ¿debería usar
espacios o tabs?

4 Espacios
¿Siempre se debe dejar un
espacio en blanco al final
de los archivos Python?

Verdadero
 Propuesta de mejora de
/01
Python
Python Enhancement Proposal.
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
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.
Tipos de PEP
Código Estado Descripción

PEP no normativo que contiene antecedentes, pautas u otra información relevante

I Informativo
para el ecosistema de Python.

PEP normativo que describe o propone un cambio en un proceso, flujo de trabajo o

P Proceso
gobernanza de la comunidad de Python.

PEP normativo con una nueva función para Python, cambio de implementación para
S Rutas estándar de trabajo
CPython o estándar de interoperabilidad para el ecosistema
Estados de los PEP
Código Estado Descripción

A Aceptado Propuesta normativa aceptada para su implementación.

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

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

<No letter> Borrador 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 Rechazado Rechazada formalmente y no será aceptada.

S Reemplazado Reemplazada por otra PEP sucesora.

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

PEP 1
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.

[Link]
PEP 20
El Zen de Python son un conjunto de
principios breves y sencillos que definen el
diseño y la funcionalidad de Python como
lenguaje de programación.

[Link]
[Link]
 Bonito es mejor que feo.
PEP 20 Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso.
La legibilidad importa.
 Los casos especiales no son lo
suficientemente especiales para romper
reglas.
Practicidad vence a la pureza.
PEP 20 Los errores nunca deberían de ocurrir
silenciosamente.
A no ser que se silencien explícitamente.
En el caso de ambigüedad, rechaza la
tentación de adivinar.
Debería de haber una – y preferiblemente
sólo una – forma obvia de hacerlo.
Aunque la forma no parezca obvia a la
primera, a no ser que seas Holandés.
 Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que «ahora
PEP 20 mismo».
Si la implementación es difícil de explicar, es
una mala idea.
Si la implementación es fácil de explicar, es
una buena idea.
Los espacios de nombres son una buena
idea, ¡usemos más de ellos!
PEP 8
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.

[Link]
[Link]
“Code is read much more
often than it is written.”
- Guido van Rossum
 ● Convenciones de nombres.
● Diseño de código.
PEP 8 ● Sangría.
● Comentarios.
● Espacios en blanco en expresiones y
declaraciones.
Convención de nombres
 Tipo Convención de nombre Ejemplos

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

Function
Separe las palabras con guiones bajos para mejorar la legibilidad.

Use una sola letra, palabra o palabras en minúsculas. x, var, my_variable

Variable
Separe las palabras con guiones bajos para mejorar la legibilidad.

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

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

Method
Separe las palabras con guiones bajos para mejorar la legibilidad.

Use una sola letra, palabra o palabras en mayúsculas. CONSTANT, MY_CONSTANT,

Constant
Separe las palabras con guiones bajos para mejorar la legibilidad. MY_LONG_CONSTANT

Use una palabra o palabras cortas en minúsculas. [Link], my_module.py

Module
Separe las palabras con guiones bajos para mejorar la legibilidad.

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

Package
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.
Distribución del código
Espacios en blanco ● Rodee las funciones y clases de
nivel superior con dos líneas en
Los espacios en blanco blanco.
verticales, o líneas en
blanco, pueden mejorar en ● Rodee las definiciones de métodos
gran medida la legibilidad de dentro de las clases con una sola
su código.
línea en blanco.
● Use líneas en blanco con
moderación dentro de las funciones
para mostrar pasos claros.
Longitud máxima de línea
y saltos de línea.
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.
Indentación
Indentación
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.
 Hack Trick:
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.
Comentarios
Comentarios en bloque
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, cómo 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.
 ● Utilice los comentarios en línea con
moderación.
Comentarios ● Escriba comentarios en línea en la
en línea misma línea que la declaración que
desea explicar.
Los comentarios en
línea explican una sola ● Separe los comentarios en línea con
declaración en una dos o más espacios de la
pieza de código. declaración.
Son útiles para ● Comience los comentarios en línea
recordar, o explicar a con un # y un solo espacio, como
otros, por qué es los comentarios de bloque.
necesaria cierta línea
de código. ● No los uses para explicar lo obvio.
 ● Rodee las cadenas de
Documentation documentación con tres comillas
Strings dobles a cada lado, ejemplo:
Los Documentation Strings, """Este es un Documentation
o docstrings, son cadenas Strings""".
entre comillas dobles (""") o
simples (''') que aparecen en ● Escríbalos para todos los módulos,
la primera línea de cualquier
función, clase, método o funciones, clases y métodos
módulo. públicos.
Puede usarlas para explicar ● Ponga el """ que finaliza una cadena
y documentar un bloque de documentación multilínea en
específico de código.
una sola línea.
Hay un PEP completo, PEP
257, que cubre ● Para Docstring de una línea,
Documentation Strings mantenga el """ en la misma línea.
 Espacios en blanco en
expresiones y declaraciones
Donde agregar ● Entre elementos separados por comas.
espacios en blanco
● Operadores de asignación (=, +=, -=, etc.)
Rodee los siguientes ● Comparaciones (==, !=, >, <, >=, <=) y (is, is
operadores binarios not, in, not in)
con un solo espacio a ● Booleanos (and, not, or)
cada lado:
 ● En slicings ([star:end:step]).
Cuándo evitar ● Entre los nombres de funciones y la
agregar espacios llamada.
en blanco
● Entre las variables y el acceso interno
usando [].
La siguiente lista
● Operaciones lógicamente unidas
describe algunos
casos en los que ● En paréntesis vacíos.
debe evitar agregar
espacios en blanco:
Recomendaciones
adicionales
 ● No compare valores booleanos con
True o False usando el operador de
equivalencia.
● Utilice el hecho de que las
Recomendaciones secuencias vacías son falsas en
adicionales declaraciones if.
● Usar 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 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.
/02 Linters
Los linters son programas que analizan el
código y marcan los errores.

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.
$ pip install flake8
$ flake8 [filename]

$ pip install pylint

$ pylint [filename]
/03 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.
$ pip install autopep8
$ autopep8 [filename]

$ pip install black

$ black [filename]
/04 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.
 $ pip install pre-commit

[Link]
 Done
[Link]