Propuesta de mejora de Python, del inglés Python Enhancement Proposal.
Los PEPs tienen como propósito ser los mecanismos primarios para proponer nuevas y mayores capacidades, para recoger la opinión de la comunidad sobre un tema, y para documentar las decisiones de diseño que se han hecho en Python.
Si deseas ver el listado completo de los PEPs puedes econtrarlo en el listado oficial de PEPs
Si estás dando tus primeos pasos en Python, hay algunas que debes conocer, si o sí, y aplicarlas: ellas son la PEP8 y la PEP20.
En Python la legibilidad es tan importante que existe una PEP para ello: la PEP8 https://www.python.org/dev/peps/pep-0008/
A continuación un listado de algunos ejemplos (no todos):
- PEP 8: Variables
- PEP 8: Constantes
- PEP 8: Clases
- PEP 8: Operadores
- PEP 8: Comentarios
- PEP 8: Indentación
- PEP 8: Líneas en blanco
Utilizar nombres descriptivos y en minúsculas. Para nombres compuestos, separar las palabras por guiones bajos.
mi_variable = 12
element = '<tag></tag>'Incorrectos:
miVariable = 12 # Incorrecto
mivariable = 12 # Incorrecto
mi-variable = 12 # Incorrecto
elem = '<tag></tag>' # IncorrectoUtilizar nombres descriptivos y en mayúsculas separando palabras por guiones bajos.
MI_CONSTANTE = 12Utilizar CapitalizedWords (CapWords o PascalCase) y siempre con nombres descriptivos.
class TestClass:Siempre colocar un espacio en blanco, antes y después de un operador
monto_bruto = 175
tasa_interes = 12
monto_interes = monto_bruto * tasa_interes / 100
tasa_bonificacion = 5
importe_bonificacion = monto_bruto * tasa_bonificacion / 100
monto_neto = (monto_bruto - importe_bonificacion) + monto_interesLos comentarios en la misma línea del código deben separarse con dos espacios en blanco. Luego del símbolo # debes agregar un solo espacio en blanco e iniciar con la primera letra en mayúscula.
first_name = 'Joe' # Nombre
last_name = 'Doe' # Apellido
age = 25 # EdadLa indentación es muy importante en Python porque indica que las instrucciones forman parte de una misma estructura de control o bloque.
La indentación en Python debe ser de 4 (cuatro) espacios en blanco.
numero = 50
if numero < 100:
print('Hola')
elif numero < 200:
print('Chao')
else:
print('Adiós')
user = ''
for char in '[email protected]':
if char == '@':
break
user += char
print(user) # Salida: 'john.smith'Indentación en la definición de colecciones largas:
# Listas
ordinales = ['primero', 'segundo', 'tercero', 'cuarto', 'quinto',
'sexto', 'séptimo', 'octavo', 'noveno', 'décimo']
# Tuplas
dias = ('lunes', 'martes', 'miércoles', 'jueves', 'viernes', 'sábado', 'domingo')
meses = ('enero', 'febrero', 'marzo', 'abril', 'mayo', 'junio',
'julio', 'agosto', 'setiembre', 'octubre', 'noviembre', 'diciembre')
# Diccionarios
usuario = {'nombre': 'Jane Doe',
'edad': 23,
'curso': 'Curso de Python',
'skills': {'programación': True,
'base_de_datos': False},
'niveles': ['básico', 'intermedio']}Las funciones y clases de nivel superior están separadas por dos líneas.
Las definiciones de métodos dentro de una clase están separadas por una sola línea en blanco.
Todo lo demás por una.
Se pueden usar líneas en blanco adicionales (con moderación) para separar grupos de funciones relacionadas. No utilice demasiadas líneas en blanco para separar segmentos lógicos en el código.
import so
import sys
from flask import Flask
def top_level_function1():
pass
def top_level_function2():
pass
class TestClass(object):
def class_method1():
pass
def class_method2():
pass
class TestClass2(object):
def class2_method1():
pass
def class2_method2():
passEl Zen de Python, escrito por Tim Peters en el año 2004, describe los principios rectores para el diseño de Python.
Puedes importarlo en tu código utlizando la siguiente instrucción.
import thisTranscribo a continuación su contenido para que puedas leerlo y luego aplicarlo.
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!