El Zen de Python

• Bello es mejor que feo: Python es estéticamente superior a cualquier otro lenguaje de programación. Al momento de escribir código, es mejor que sea de manera limpia y estética.
• Explícito es mejor que implícito: Hacer más fácil que las otras personas entiendan el código.
• Simple es mejor que complejo: Es mejor tener una implementación simple, que ocupe pocas líneas de código y sea entendible, a que sea una larga y complicada.
• Complejo es mejor que complicado: Si tenemos que extendernos en la implementación y hacerla más compleja para que el código si se entienda, esto es mejor que hacerlo simple y mal.
• Plano es mejor que anidado: El anidamiento es cuando tenemos un bloque de código dentro de otro bloque de código (dependiendo de este). Esto se nota en Python por la indentación, nos quedarían estos bloques muy corridos a la derecha. Es mejor evitar el anidamiento, y hacer las cosas de manera plana.
• Espaciado es mejor que denso: Por la indentación de Python (sus sangrías), este principio se nos hace imposible de esquivar. El código inevitablemente es espaciado.
• **La legibilidad es importante:**Es importante que otros programadores puedan entender lo que estamos escribiendo. Esto hace más fáciles las cosas cuando trabajemos con otros en los proyectos.
• Los casos especiales no son lo suficientemente especiales como para romper las reglas (sin embargo, la practicidad le gana a la pureza): Siempre que podamos respetar estas reglas que nos plantea Python, es mejor así. Sin embargo, si por el hecho de hacer un código muy puro o muy ‘Pythonista’, este pierde legibilidad, es mejor ser más prácticos y romper o saltearnos algunas de estas reglas para que el código sea más eficiente. Por lo tanto, llegado el momento debemos decidir si es mejor hacer las cosas de manera pura o práctica.
• Los errores nunca deberían pasar silenciosamente (a menos que se silencien explícitamente): Manejar los errores es fundamental. Cada error nos dice algo y hay que prestarle atención. A menos que seas capaz de silenciar un error explícitamente, aunque para esto hay que tener criterio.
• Frente a la ambigüedad, evitar la tentación de adivinar: Nuestro código debería solamente tener una interpretación. Si en un contexto significa algo, y en otro otra cosa, es mejor que lo revisemos y busquemos una solución.
• Debería haber una, y preferiblemente sola, una manera obvia de hacerlo. (A pesar de que esa manera no sea obvia a menos que seas holandés): Esto hace referencia al creador de Python ''Guido van Rossum", que de manera muy inteligente encontrar las soluciones precisas a los problemas, y deberíamos imitarlo.
• Ahora es mejor que nunca: Es mejor desarrollar nuestra solución cuánto antes, no dejarlo para mañana o para más adelante.
• A pesar de que nunca es muchas veces mejor que ahora mismo: Si por hacer las cosas ya y tenemos poco tiempo, si es mejor dejarlo para después y no hacerlo apurado y mal.
• Si la implementación es difícil de explicar, es una mala idea, y si es fácil de explicar, es una buena idea: Si somos capaces de explicar nuestra implementación a otros desarrolladores paso a paso, es una buena idea. En cambio si no podemos hacerlo, significa que ni nosotros entendemos la implementación y deberíamos repensar nuestra forma de encarar la solución.

¿Qué es la documentación?

• Básicamente es lo que nos explica cómo funciona un determinado lenguaje, es como una manual de instrucciones sobre el lenguaje de programación que deseamos aprender.
• La documentación es la que nos dirá cómo funciona cualquier lenguaje o tecnología ( Si conoces cómo funciona algo tienes ventaja por encima de los que solo conocen su estructura básica). ¡ES MUY IMPORTANTE CONSULTAR LA DOCUMENTACIÓN DE VEZ EN CUANDO!
• ¿Qué es el índice PEP (Propuestas de mejoras de Python)