1 de 14

Bitcora
Traducciones
Tutorial de Python

Gua de estilo del cdigo Python

Por Guido van Rossum, Barry Warsaw
Traduccin al castellano por Ral Gonzlez Duque
el da 10 de Agosto de 2007

Introduccin
En este documento se listan distintas convenciones utilizadas en el cdigo Python comprendido en la librera
estndar de la distribucin principal de Python. Por favor refierase al PEP que describe las guas de estilo del
cdigo C para la implementacin en C de Python[1].
Este documento es una adaptacin del ensayo original de Guido Gua de Estilo de Python[2], con algunos
aadidos de la gua de estilo de Barry[5]. En los puntos en los que exista conflicto, se aplican las reglas de
estilo de Guido para los propsitos de este PEP. Este PEP puede estar an incompleto (de hecho, es posible
que nunca llegue a completarse ).

La Consistencia Estpida es el Demonio de las Mentes Pequeas

Una de las ideas clave de Guido es que el cdigo se suele leer mucho ms de lo que se escribe. Las guas de
estilo que proporciona este documento estn dirigidas a mejorar la legibilidad del cdigo y hacerlo
consistente a lo largo del amplio espectro del cdigo Python. Como dice el PEP 20[6], "La legibilidad
cuenta".
Una gua de estilo nos ayuda a lograr consistencia. Ser consistente con esta gua de estilo es importante. La
consistencia dentro de un proyecto es an ms importante. La consistencia dentro de un mdulo o funcin es
la ms importante.
Pero lo ms importante es saber cundo ser inconsistente -- algunas veces la gua de estilo simplemente no es
aplicable. Cuando tengas dudas, usa tu juicio. Mira ejemplos y decide qu te parece mejor. Y no dudes en
preguntar!
Dos buenas razones para romper una regla en particular son:
1. Que al aplicar la regla el cdigo se haga menos legible, incluso para alguien que est acostumbrado a
leer cdigo que sigue las normas.
2. Para ser consistente con cdigo relacionado que tambin la rompe (quizs por razones histricas) -aunque esto tambin es una oportunidad de arreglar el desaguisado de otra persona (al ms puro estilo
XP).

Formateo del cdigo

Indentacin
Usa 4 espacios por cada nivel de indentacin.
Para cdigo realmente antiguo que no quieras estropear, puedes continuar usando tabuladores de 8 espacios.

2 de 14

Tabuladores o espacios?
Nunca mezcles tabuladores y espacios.
La forma ms popular de indentar en Python es utilizar slo espacios. La segunda forma ms popular es usar
slo tabuladores. El cdigo indentado con una mezcla de tabuladores y espacios debera reformatearse y usar
espacios exclusivamente. Cuando se invoca el intrprete de lnea de comandos de Python con la opcin -t,
este muestra avisos sobre cdigo que mezcla tabuladores y espacios. Cuando se utiliza -tt estos avisos se
convierten en errores. Estas opciones son altamente recomendables!
Para nuevos proyectos, se recomienda firmemente el uso de espacios en lugar de tabuladores. La mayora de
los editores tienen caractersticas que hacen esto bastante sencillo.

Tamao mximo de lnea

Limita todas las lneas a un mximo de 79 caracteres.
Todava existen muchos dispositivos por ah que estn limitados a 80 caracteres por lnea; adems limitando
el ancho de las ventanas a 80 caracteres posibilitas el tener varias ventanas una al lado de otra. El ajuste de
lnea por defecto en este tipo de dispositivos no da buenos resultados. Por lo tanto, por favor limita todas las
lneas a un mximo de 79 caracteres. Para cadenas de texto largas (cadenas de documentacin o
comentarios), es aconsejable limitar el ancho a 72 caracteres.
La forma preferida de dividir lneas largas es utilizar la caracterstica de Python de continuar las lneas de
forma implcita dentro de parntesis, corchetes y llaves. Si es necesario, puedes aadir un par de parntesis
extra alrededor de una expresin, pero algunas veces queda mejor usar una barra invertida. Asegurate de
indentar la lnea siguiente de forma apropiada. Algunos ejemplos:
class Rectangle(Blob):
def __init__(self, width, height,
color='black', emphasis=None, highlight=0):
if width == 0 and height == 0 and \
color == 'red' and emphasis == 'strong' or \
highlight > 100:
raise ValueError("sorry, you lose")
if width == 0 and height == 0 and (color == 'red' or
emphasis is None):
raise ValueError("I don't think so")
Blob.__init__(self, width, height,
color, emphasis, highlight)

Lneas en blanco
Separa las funciones no anidadas y las definiciones de clases con dos lneas en blanco.
Las definiciones de mtodos dentro de una misma clase se separan con una lnea en blanco.
Se pueden usar lneas en blanco extra (de forma reservada) para separar grupos de funciones relacionadas.
Las lneas en blanco se pueden omitir entre un grupo de funciones con una sola lnea (por ejemplo, con un
conjunto de funciones sin implementacin).
Usa lneas en blanco en las funciones, de forma limitada, para indicar secciones lgicas.
Python acepta el caracter control-L (o lo que es lo mismo ^L) como un espacio en blanco; muchas
herramientas utilizan este caracter como separador de pginas, por lo que puedes usarlos para separar
pginas de secciones relacionadas en tu archivo.

3 de 14

Codificacin de caracteres (PEP 263)

El cdigo de la distribucin base de Python siempre debera utilizar las codificaciones ASCII o Latin-1
(tambin conocida como ISO-8859-1). Para Python 3.0 y superiores, se recomienda UTF-8 en lugar de
Latin-1, ver PEP 3120.
Los archivos que usan ASCII (o UTF-8, para Python 3.0) no deberan tener una lnea de especificacin del
juego de caracteres. Slo debera usarse Latin-1 (o UTF-8) cuando se necesite mencionar a un autor cuyo
nombre requiera de caracteres Latin-1 en un comentario o cadena de documentacin; si no es as, la forma
adecuada de incluir datos no ASCII en literales de cadena es mediante los caracteres de escape \x, \u y \U.
Para Python 3.0 y superiores, se recomienda la siguiente poltica para la librera estndar (ver PEP 3131):
Todos los identificadores en la librera estndar Python DEBEN usar slo caracteres ASCII, y DEBERAN
usar palabras en ings siempre que esto sea posible (en muchos casos se utilizan abreviaturas y trminos
tcnicos que no forman parte del ingls). Adems, los literales de cadena y los comentarios tambin deben
estar en ASCII. Las nicas excepciones son (a) bateras de pruebas que comprueben las caractersticas no
ASCII, y (b) nombres de autores. Los autores cuyos nombres no estn basados en el alfabeto latino DEBEN
proporcionar una transcripcin de sus nombres a este alfabeto.
Se recomienda a los proyectos de cdigo abierto con audiencia global que adopten polticas similares.

Imports
Normalmente los imports deberan colocarse en distintas lneas, por ejemplo:
S:
import os
import sys

No:
import sys, os

aunque tambin es correcto hacer esto:

from subprocess import Popen, PIPE

Los imports se colocan siempre en la parte superior del archivo, justo despus de cualquier comentario
o cadena de documentacin del mdulo, y antes de las variables globales y las constantes del mdulo.
Los imports deberan agruparse siguiendo el siguiente orden:
1. imports de la librera estndar
2. imports de proyectos de terceras partes relacionados
3. imports de aplicaciones locales/imports especficos de la librera
Deberas aadir una lnea en blanco despus de cada grupo de imports.
Si es necesario especificar los nombres pblicos definidos por el mdulo con __all__ esto debera
hacerse despus de los imports.
Es muy desaconsejable el uso de imports relativos para importar cdigo de un paquete. Utiliza siempre
la ruta absoluta del paquete para todos los imports. Incluso ahora que el PEP 328 [7] est totalmente
implementado en Python 2.5, el usar imports relativos se desaconseja seriamente; los imports
absolutos son ms portables y normalmente ms legibles.

4 de 14

Cuando importes una clase de un mdulo, normalmente es correcto hacer esto

from myclass import MyClass
from foo.bar.yourclass import YourClass

Si esto causa colisiones de nombres con objetos locales, utiliza en su lugar

import myclass
import foo.bar.yourclass

y usa "myclass.MyClass" y "foo.bar.yourclass.YourClass" en el cdigo

Espacios en blanco en expresiones y sentencias

Evita espacios en blanco extra en las siguientes situaciones:
Inmediatamente despus de entrar en un parntesis o antes de salir de un parntesis, corchete o llave.
S:
spam(ham[1], {eggs: 2})

No:
spam( ham[ 1 ], { eggs: 2 } )

Inmediatamente antes de una coma, punto y coma, o dos puntos:

S:
if x == 4: print x, y; x, y = y, x

No:
if x == 4 : print x , y ; x , y = y , x

Inmediatamente antes de abrir un parntesis para una lista de argumentos de una llamada a una
funcin:
S:
spam(1)

No:
spam (1)

Inmediatamente antes de abrir un parntesis usado como ndice o para particionar (slicing):
S:
dict['key'] = list[index]

No:
dict ['key'] = list [index]

5 de 14

Ms de un espacio alrededor de un operador de asignacin (u otro operador) para alinearlo con otro.
S:
x = 1
y = 2
long_variable = 3

No:
x
= 1
y
= 2
long_variable = 3

Otras Recomendaciones
Rodea siempre los siguientes operadores binarios con un espacio en cada lado: asignacin (=),
asignacin aumentada (+=, -= etc.), comparacin (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
booleanos (and, or, not).
Usa espacios alrededor de los operadores aritmticos:
S:
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

No uses espacios alrededor del signo '=' cuando se use para indicar el nombre de un argumento o el
valor de un parmetro por defecto.
S:
def complex(real, imag=0.0):
return magic(r=real, i=imag)

No:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)

Generalmente se desaconsejan las sentencias compuestas (varias sentencias en la misma lnea).

S:
if foo == 'blah':
do_blah_thing()
do_one()
do_two()
do_three()

Preferiblemente no:
if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()

6 de 14

Aunque a veces es adecuado colocar un if/for/while con un cuerpo pequeo en la misma lnea, nunca
lo hagas para sentencias multi-clausula.
Preferiblemente no:
if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()

Definitivamente no:
if foo == 'blah': do_blah_thing()
else: do_non_blah_thing()
try: something()
finally: cleanup()
do_one(); do_two(); do_three(long, argument,
list, like, this)
if foo == 'blah': one(); two(); three()

Comentarios
Los comentarios que contradicen el cdigo son peores que no tener ningn comentario. Manten siempre
como prioridad el mantener los comentarios actualizados cuando cambies el cdigo!
Los comentarios deberan ser frases completas. Si un comentario es una frase o sentencia, la primera palabra
debera estar en maysculas, a menos que sea un identificador que comience con una letra en minsculas
(nunca alteres el identificador sustituyendo maysculas o minsculas!).
Si un comentario es corto, se puede omitir el punto al final. Los comentarios de bloque generalmente
consisten en uno o ms prrafos construidos con frases completas, y cada frase debera terminar con un
punto.
Deberas usar dos espacios despus de un punto de final de lnea.
Cuando escribas en ingls, aplica las reglas de Strunk y White (N.T: Los autores de "The Elements of Style",
un conocido libro de estilo de escritura en ingls).
Para los programadores en Python que no sean de pases de habla inglesa: por favor escribe tus comentarios
en ingls, a menos que ests un 120% seguro de que el cdigo nunca ser ledo por gente que no hable tu
idioma.

Comentarios de bloque
Los comentarios de bloque generalmente se aplican al cdigo que se encuentra a continuacin, y se indentan
al mismo nivel que dicho cdigo. Cada lnea de un comentario de bloque comienza con un # y un nico
espacio (a menos que haya texto indentado dentro del comentario).
Los prrafos dentro de un comentario de bloque se separan por una lnea conteniendo un nico #.

Comentarios en lnea
Utiliza comentarios en lnea de forma moderada.
Un comentario en lnea es un comentario que se encuentra en la misma lnea que una sentencia. Los
comentarios en lnea deberan separarse por al menos dos espacios de la sentencia que comentan. Deberan
comenzar con un # y un espacio.

7 de 14

Los comentarios en lnea son innecesarios y de hecho slo sirven para distraer si indican cosas obvias. No
hagas cosas como esta:
x = x + 1

# Incrementa x

Aunque a veces, algo como esto puede ser de utilidad:

x = x + 1

# Compensa por el borde

Cadenas de Documentacin
Las convenciones para escribir buenas cadenas de documentacin (tambin llamados "docstrings") se
inmortalizaron en el PEP 257 [3].
Escribe docstrings para todos los mdulos, functiones, clases, y mtodos pblicos. Los docstrings no
son necesarios para mtodos no pblicos, pero deberas tener un comentario que describa lo que hace
el mtodo. Este comentario debera aparecer antes de la lnea "def".
El PEP 257 describe las convenciones para buenas cadenas de documentacin. Es importante notar,
que el """ que finaliza un docstring de varias lneas debera situarse en una lnea separada, y
preferiblemente precederse por una lnea en blanco, por ejemplo:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""

Para cadenas de documentacin de una lnea, es adecuado mantener el """ de cierre en la misma lnea.

Mantenimiento de datos de versin

Si necesitas incluir datos de Subversion, CVS, o RCS en tus archivos de cdigo fuente, hazlo de la siguiente
forma.
__version__ = "$Revision: 56036 $"
# $Source$

Estas lneas deberan incluirse antes de la cadena de documentacin del mdulo, antes de cualquier otro
cdigo, y separadas por una lnea en blanco encima y debajo.

Convenciones de nombres
Las convenciones de nombres de la librera de Python son un pequeo desastre, as que nunca
conseguiremos que sea completamente consistente -- an as, aqu tenis los estndares de nombrado
recomendados en la actualidad. Los nuevos mdulos y paquetes (incluyendo los frameworks de terceras
personas) deberan acomodarse a estos estndares, pero donde exista una librera con un estilo distinto, se
prefiere la consistencia interna.

Descriptivo: Estilos de Nombrado

Hay un montn de estilos de nombrado distintos. Ayuda el poder reconocer qu estilo de nombrado se
utiliza, independientemente de para lo que se utilice.
Podemos encontrarnos con los siguientes estilos de nombrado ms comunes:

8 de 14

b (una sola letra en minsculas)

B (una sola letra en maysculas)
minusculas
minusculas_con_guiones_bajos
MAYUSCULAS
MAYUSCULAS_CON_GUIONES_BAJOS
PalabrasEnMayusculas (CapWords o CamelCase -- llamado as por el parecido de las maysculas con
las jorobas de los camellos[4]). Algunas veces tambin se llaman StudlyCaps.
Nota: Cuando se usan abreviaturas en CapWords, mantn en maysculas todas las letras de la
abreviatura. Por lo tanto HTTPServerError es mejor que HttpServerError.
capitalizacionMezclada (se diferencia de PalabrasEnMayusculas porque la primera letra est en
minsculas!)
Mayusculas_Con_Guiones_Bajos (feo!)
Tambin existe un estilo en el cul se utiliza un prefijo nico corto para agrupar nombres relacionados de
forma conjunta. Esto no se suele utilizar mucho en Python, pero se menciona con el objeto de que el texto
sea lo ms completo posible. Por ejemplo, la funcin os.stat() devuelve una tupla cuyos elementos
tradicionalmente han tenido nombres como st_mode, st_size, st_mtime y similares. (Esto se hace para
enfatizar la correspondencia con los campos de la estructura de la llamada a sistema POSIX, lo cual es de
utilidad para los programadores que estn familiarizados con ella.)
La librera X11 utiliza una X inicial para todas sus funciones pblicas. En Python, este estilo generalmente se
considera innecesario porque los atributos y mtodos se preceden por el objeto al que pertenencen, y los
nombres de funciones se preceden del nombre del mdulo.
Adems se reconocen las siguientes formas especiales usando guiones bajos al inicio o final del nombre
(generalmente estos se pueden combinar con cualquier convencin de capitalizacin):
_guion_bajo_al_inicio: indicador dbil de "uso interno". Por ejemplo "from M import *" no importa
objetos cuyos nombres comiencen con un guin bajo.
guion_bajo_al_final_: usado por convencin para evitar conflictos con palabras clave de Python, por
ejemplo
Tkinter.Toplevel(master, class_='ClassName')

__doble_guion_bajo_al_inicio: cuando se use para nombrar un atributo de clase, invoca la

caracterstica de "planchado de nombres" (dentro de la clase FooBar, __boo se convierte en
_FooBar__boo; ver abajo).
__doble_guion_bajo_al_inicio_y_fin__: objectos "mgicos" o atributos que viven en espacios de
nombres controlados por el usuario. Por ejemplo __init__, __import__ o __file__. Nunca inventes
nombres como estos; utilizalos slo como estn documentados.

Prescriptivo: Convenciones de Nombrado

Nombres a Evitar

9 de 14

Nunca utilices los caracteres 'l' (letra ele minscula), 'O' (letra o mayscula), o 'I' (letra i mayscula) como
nombres de variables de un solo caracter.
En algunas fuentes, estos caracteres son indistinguibles de los numerales uno y cero. Cuando estes tentado
de usar 'l', utiliza una 'L' en su lugar.
Nombres de Paquetes y Mdulos
Los mdulos deberan tener nombres cortos formados en su totalidad por letras minsculas. Se puede utilizar
guiones bajos en el nombre del mdulo si mejora la legibilidad. Los paquetes Python tambin deberan tener
nombres cortos formados de letras minsculas, aunque se desaconseja el uso de guiones bajos.
Dado que los nombres de los mdulos se mapean a nombres de archivos, y algunos sistemas de ficheros no
diferencian entre maysculas y minsculas y truncan los nombres largos, es importante que los nombres de
los mdulos que se elijan sean suficientemente cortos -- esto no es un problema en Unix, pero puede ser un
problema cuando el cdigo se porta a versiones antiguas de Mac o Windows, o a DOS.
Cuando un mdulo de extensin escrito en C o C++ tenga un mdulo Python asociado que proporcione una
interfaz de ms alto nivel (por ejemplo, ms orientado a objetos), el mdulo C/C++ debera comenzar con un
guin bajo (por ejemplo _socket).
Nombres de Clases
Casi sin excepciones, los nombres de clases usan la convencin CapWords. Las clases de uso interno tienen
adems un guin bajo al principio del nombre.
Nombres de Excepciones
Dado que las excepciones deberan ser clases, se aplica la convencin relativa al nombrado de clases. De
todas formas, deberas usar el sufijo "Error" en los nombres de las excepciones (si la excepcin es realmente
un error).
Nombres de Variables Globales
(Esperamos que estas variables estn destinadas a ser usadas slo dentro de un mdulo.) Las convenciones
son prcticamente las mismas que para las funciones.
Los mdulos diseados para ser utilizados usando "from M import *" deberan usar el mecanismo __all__
para prevenir que se exporten variables globales, o bien usar la convencin antigua de aadir un guin bajo
como prefijo a dichas variables globales (puede que quieras hacer esto para indicar que estas variables son
"variables no pblicas del mdulo").
Nombres de Funciones
Los nombres de funciones deberan estar en letras minsculas, con palabras separadas mediante guiones
bajos segn sea necesario para mejorar la legibilidad.
Slo se acepta capitalizacionMezclada en contextos en los que ya se trate del estilo principal (por ejemplo
threading.py), para mantener la compatibilidad hacia atrs.
Argumentos de funciones y mtodos
Utiliza siempre 'self' como primer argumento de los mtodos de instancia.

10 de 14

Utiliza siempre 'cls' como primer argumento de mtodos de clase.

Si el nombre de un argumento de una funcin colisiona con una palabra reservada, generalmente es mejor
aadir un guin bajo al final del nombre en lugar de usar una abreviatura o modificar la grafa. Por lo tanto
"print_" se considera mejor que "prnt". (Quizs utilizar sinnimos sea una forma incluso mejor.)
Nombres de mtodos y variables de instancia
Utiliza las reglas de los nombres de funciones: minsculas con palabras separadas por guiones bajos cuando
sea necesario para mejorar la legibilidad.
Utiliza guiones bajos al inicio slo para mtodos no pblicos y variables de instancia.
Para evitar colisiones de nombres con subclases, utiliza dos guiones bajos al principio del nombre para
invocar las reglas de planchado de nombres de Python.
Python une estos nombres con el nombre de la clase: si la clase Foo tiene un atributo llamado __a, no se
puede acceder utilizando Foo.__a. (Un usuario insistente podra acceder utilizando Foo._Foo__a.)
Generalmente, slo se debera usar un doble guin al inicio para evitar conflictos de nombres con atributos
en clases diseadas para que se herede de ellas.
Nota: existe controversia sobre el uso de __nombres (ver debajo).
Disear para la herencia
Decide siempre si los mtodos y variables de instancia de una clase (llamados de forma colectiva "atributos")
deberan ser pblicos o no pblicos. Si dudas, elige que sea no pblico; es ms sencillo convertirla en pblico
ms tarde que hacer no pblico un atributo que antes era pblico.
Los atributos pblicos son aquellos que esperas que sean utilizados por los clientes de tu clase, y para los
cuales te comprometes a evitar cambios que provoquen incompatibilidades hacia atrs. Los atributos no
pblicos son aquellos que no estn destinados a que sean utilizados por terceras personas; no ofreces ninguna
garanta de que los atributos no pblicos no vayan a cambiar o a eliminarse.
No utilizamos el trmino "privado" aqu, dado que ningn atributo es realmente privado en Python (sin un
trabajo aadido generalmente innecesario).
Otra categora de atributos son aquellos que son parte de la "API de las subclases" (a menudo llamado
"protected" en otros lenguajes). Algunas clases se disean para que se herede de ellas, bien para extender o
bien para modificar aspectos del comportamiento de la clase. Cuando se disea una clase de esta forma, es
necesario tomar algunas decisiones explcitas sobre qu atributos van a ser pblicos, cules son parte de la
API de la subclase, y cules estn pensados para ser utilizados exclusivamente dentro de la clase actual.
Teniendo esto en cuenta, aqu estn las lneas a seguir:
Los atributos pblicos no deberan tener guiones bajos al inicio del nombre.
Si el nombre de tu atributo pblico colisiona con el de una palabra reservada, aade un nico guin
bajo al final del nombre del atributo. Esto es preferible a abreviar o cambiar la grafa de la palabra.
Nota 1: Ver la recomendacin anterior para mtodos de clase.
Para campos pblicos simples, es mejor exponer slo el nombre del atributo, sin complicaciones de
mtodos para accederlos y modificarlos (accessors y mutators). Ten en cuenta que Python proporciona
una forma sencilla de modificarlo, en caso de que dentro de un tiempo lo necesites. En ese caso, utiliza
propiedades para ocultar la implementacin funcional con una sintaxis simple de acceso a atributos de

11 de 14

datos.
Nota 1: Las propiedades slo funcionan en las nuevas clases.
Nota 2: Intenta mantener el comportamiento funcional libre de efectos colaterales, aunque
funcionalidad colateral como el cacheo generalmente es aceptable.
Nota 3: Evita usar propiedades para realizar operaciones que requieran de grandes clculos; el utilizar
la notacin de atributos hace que la persona que accede al atributo piense que el acceso es
(relativamente) barato en tiempo computacional.

Recomendaciones para la programacin

El cdigo debera escribirse de forma que no pusiera en desventaja otras implementaciones de Python
(PyPy, Jython, IronPython, Pyrex, Psyco, y similares).
Por ejemplo, no te apoyes en la eficiencia de la implementacin de la concatenacin de cadenas con
a+=b o a=a+b en CPython. Estas rdenes se ejecutan ms lentamente en Jython. En partes de la
librera en las que el rendimiento sea importante, se debera utilizar en su lugar la forma ''.join(). Esto
asegura que el tiempo necesario para la concatenacin es del mismo orden en diferentes
implementaciones.
Las comparaciones con singletons como None siempre deberan llevarse a cabo con 'is' o 'is not', nunca
con operadores de igualdad.
Tambin es importante tener cuidado con escribir "if x" cuando lo que realmente queramos decir es
"if x is not None" -- por ejemplo, cuando comprobemos si a una variable o argumento que tiene como
valor por defecto None se le ha dado otro valor. El otro valor podra tener un tipo (como un
contenedor) que podra ser falso en un contexto booleano!
Utiliza excepciones basadas en clases.
Las excepciones en forma de cadenas estn prohibidas en el cdigo nuevo, dado que esta
caracterstica del lenguaje se eliminar en Python 2.6.
Los mdulos o paquetes deberan definir sus propias clases excepcin especficas para el dominio del
problema, las cuales deberan heredar de la clase Exception. Incluye siempre una cadena de
documentacin para la clase. Por ejemplo:
class MessageError(Exception):
"""Base class for errors in the email package."""

En este caso se aplican las convenciones de nombrado de las clases, aunque deberas aadir el sufijo
"Error" a las clases excepcin, si la excepcin se trata de un error. Las excepciones que no sean
errores, no necesitan ningn sufijo especial.
Cuando lances una excepcin, utiliza "raise ValueError('mensaje')" en lugar de la forma antigua
"raise ValueError, 'mensaje'".
Se prefiere la forma con parntesis porque cuando los argumentos de la excepcin son largos o
incluyen formateo de cadenas, no necesitas usar caracteres para indicar que contina en la siguiente
lnea gracias a los parntesis. La forma antigua se eliminar en Python 3000.
Cuando captures excepciones, menciona excepciones especficas cuando sea posible en lugar de
utilizar una clausula 'except:' genrica.
Por ejemplo, utiliza:

12 de 14

try:
import platform_specific_module
except ImportError:
platform_specific_module = None

Una clusula 'except:' genrica capturara las excepciones SystemExit y KeyboardInterrupt,

complicando el poder interrumpir el programa usando Control-C, y pudiendo ocultar otros problemas.
Si quieres capturar todas las excepciones relativas a errores en el programa, utiliza 'except Exception:'.
Una buena regla a seguir es limitar el uso de las clasulas 'except' genricas a dos casos:
1. Si el manejador de la excepcin imprimir o registrar el traceback; de esta forma al menos el
usuario sabr que ha ocurrido un error.
2. Si el cdigo tiene que realizar algn trabajo de limpieza, pero en ese caso tenemos que hacer que
la excepcin se propague hacia arriba usando 'raise'. La construccin 'try...finally' es una mejor
forma de tratar con este caso.
Adicionalmente, para todas las clausulas try/except, es necesario limitar la clausula 'try' a la mnima
expresin de cdigo necesaria. De nuevo, esto se hace para evitar ocultar bugs.
S:
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)

No:
try:
# Demasiado amplio!
return handle_value(collection[key])
except KeyError:
# Tambin capturar la excepcin KeyError lanzada por handle_value()
return key_not_found(key)

Utiliza mtodos de cadenas en lugar del mdulo string.

Los mtodos de las cadenas son siempre mucho ms rpidos y comparten la misma API con las
cadenas unicode. Ignora esta regla si es necesaria compatibilidad hacia atrs con versiones de Python
anteriores a la 2.0.
Utiliza ''.startswith() y ''.endswith() en lugar del particionado de cadenas para comprobar prefijos y
sufijos.
startswith() y endswith() son ms limpios y menos propensos a errores. Por ejemplo:
S:
if foo.startswith('bar'):

No:
if foo[:3] == 'bar':

La excepcin a esta norma se da si es necesario que el cdigo funcione con Python 1.5.2 (esperemos
que no lo necesites!).

13 de 14

Las comparaciones del tipo de objeto siempre deberan utilizar isinstance() en lugar de comparar tipos
directamente.
S:
if isinstance(obj, int):

No:
if type(obj) is type(1):

Cuando comprobemos si un objeto es una cadena, hay que tener en cuenta que puede que se trate de
una cadena unicode! En Python 2.3, str y unicode tienen una clase padre comn, basestring, por lo que
puedes usar:
if isinstance(obj, basestring):

En Python 2.2, el mdulo types define el tipo StringTypes para este propsito en concreto, por
ejemplo:
from types import StringTypes
if isinstance(obj, StringTypes):

En Python 2.0 y 2.1, tendramos que hacer:

from types import StringType, UnicodeType
if isinstance(obj, StringType) or \
isinstance(obj, UnicodeType) :

Para secuencias, (cadenas, listas, tuplas), aprovecha el que las secuencias vacias son equivalentes al
falso booleano.
S:
if not seq:
if seq:

No:
if len(seq)
if not len(seq)

No compares valores booleanos con True o False usando ==

S:
if greeting:

No:
if greeting == True:

Peor:
if greeting is True:

Referencias
[1] PEP 7, Gua de Estilo para Cdigo C, van Rossum
[2] http://www.python.org/doc/essays/styleguide.html
[3] PEP 257, Convenciones para Cadenas de Documentacin, Goodger, van Rossum

14 de 14

[4] http://www.wikipedia.com/wiki/CamelCase
[5] Gua de estilo de GNU Mailman de Barry http://barry.warsaw.us/software/STYLEGUIDE.txt
[6] PEP 20, El Zen de Python
[7] PEP 328, Imports: Multi-Line and Absolute/Relative