El Zen de Python

El Zen de Python se compone por los principios para escribir tu código de manera clara, sencilla y precisa. Estos son:

• Bello es mejor que feo:
  Pyhton 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 lineas 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 identació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 identació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 cpmo 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 debermos 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 erroes 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 ambiguedad, 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 mas 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 díficil 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.
• **Los espacios de nombres son una gran idea, ¡Tengamos más de esos! (namespaces):
  Es el nombre que se ha indicado luego de la palabra import, es decir la ruta (namespace) del módulo. (Lo veremos a profundidad más adelante).

Hice un pequeño sitio web que básicamente es un test para que repasen el Zen de Python, es solo con motivos de aprendizaje, para que puedan tener más en claro el Zen de Python cuando trabajen con él, no es necesario aprenderselo de memoria, pero ayuda tenerlo claro 😄.
.
Lo hice con Vue, solo tiene 15 preguntas así que si quieren darle un vitazo, aquí les dejo el link:
.
El Zen del Python
.
Por cierto, es Open Source, pueden clonar o hacer fork del repositorio por si gustan 😄
.
RetaxMaster/python-zen
.

El Zen de Python 🧘🏼‍♂️

Una excelente filosofía que les comparto en una imagen para llevar 😄

El zen de python, son un conjunto de consejos para llegar a subir de nivel y convertirte en un profesional programando con este lenguaje para ello te comparto su zen♥

El Zen de python son los principios de este lenguaje

• Bello es mejor que feo.
• Explícito es mejor que implícito.
• Simple es mejor que complejo.
• Complejo es mejor que complicado.
• Plano es mejor que anidado.
• Espaciado es mejor que denso.
• La legibilidad es importante.
• Los casos especiales no son lo suficientemente especiales como para romper las reglas.
• Sin embargo la practicidad le gana a la pureza.
• Los errores nunca deberían pasar silenciosamente.
• A menos que se silencien explícitamente.
• Frente a la ambigüedad, evitar la tentación de adivinar.
• Debería haber una, y preferiblemente solo una, manera obvia de hacerlo.
• A pesar de que esa manera no sea obvia a menos que seas Holandés.
• Ahora es mejor que nunca.
• A pesar de que nunca es muchas veces mejor que ahora mismo.
• Si la implementación es difícil de explicar, es una mala idea.
• Si la implementación es fácil de explicar, puede que sea una buena idea.
• Los espacios de nombres son una gran idea, ¡tengamos más de esos!

Para ver el Zen de Python lo podemos ver desde la consola cuando importamos el módulo this

>>> import this 

También existen otros módulos secretos 👀

>>> import antigravity

>>> import __hello__
Hello world!

Quería mostrarles python vs otros lenguajes…
En serio python hace la vida más fácil

Genial!
![](

Es interesante que el zen de Python sean los 20 principios más importantes, pero que en realidad sean 19 😄 Esto, según estuve investigando se puede deber a dos casos:

1. Según algunas personas Guido ha dicho que fue un joke por parte de Tim.
2. Otras discusiones dicen que también puede que haya sido la forma de Tim de permitir que el desarrollador añadiera un principio propio.

Sea cual sea la razón real, si es una de estas dos, es espectacular la respuesta. 😃

1. Lo bello es mejor que lo feo.
2. Explícito es mejor que implícito.
3. Lo simple es mejor que lo complejo.
4. Complejo es mejor que complicado.
5. Plano es mejor que anidado.
6. Es mejor escaso que denso.
7. La legibilidad cuenta.
8. Los casos especiales no son lo suficientemente especiales como para romper las reglas.
9. Aunque la practicidad vence a la pureza.
10. Los errores nunca deben pasar silenciosamente.
11. A menos que esté explícitamente silenciado.
12. Ante la ambigüedad, rechace la tentación de adivinar.
13. Debe haber una, y preferiblemente solo una, forma obvia de hacerlo.
14. Aunque esa forma puede no ser obvia al principio a menos que seas holandés.
15. Ahora es mejor que nunca.
16. Aunque a menudo nunca es mejor que * ahora mismo *.
17. Si la implementación es difícil de explicar, es una mala idea.
18. Si la implementación es fácil de explicar, puede ser una buena idea.
19. Los espacios de nombres son una gran idea, ¡hagamos más!

El zen de Python
Fue escrito por Tim Peters con “20” aforismos que nos marcan las pautas para escribir un código pytonístico (claro, sencillo y preciso)

El Zen de python:

1. Bello es mejor que feo.
2. Explícito es mejor que implícito.
3. Simple es mejor que complejo.
4. Complejo es mejor que complicado.
5. Plano es mejor que anidado.
6. Espaciado es mejor que denso.
7. La legibilidad es importante.
8. Los casos especiales no son lo suficientemente especiales como para romper las reglas.
9. Sin embargo la practicidad le gana a la pureza.
10. Los errores nunca deberían pasar silenciosamente.
11. A menos que se silencien explícitamente.
12. Frente a la ambigüedad, evitar la tentación de adivinar.
13. Debería haber una, y preferiblemente solo una, manera obvia de hacerlo.
14. A pesar de que esa manera no sea obvia a menos que seas Holandés.
15. Ahora es mejor que nunca.
16. A pesar de que nunca es muchas veces mejor que ahora mismo.
17. Si la implementación es difícil de explicar, es una mala idea.
18. Si la implementación es fácil de explicar, puede que sea una buena idea.
19. Los espacios de nombres son una gran idea, ¡tengamos más de esos!
    … conoces el aforismo 20 del Zen de Python?

Al igual que cada arquitecto/a impregna sus creaciones con su propia visión y personalidad, o la cocina de cada chef suele tener una esencia única, cada desarrollador/a escribe código según sus gustos, por lo que el código de diferentes desarrolladores/as suele ser muy heterogéneo (diferente).

Pero y ¿si se tuvieran unas directrices a seguir, que ayudaran a discernir de qué forma hay que escribir en cada lenguaje? ¿no sería mucho más simple tener una forma, y solo una forma, de escribir código? con esta motivación se definió la PEP 20 o el Zen de Python.

Un curso de Python con Python 3.9.1…Señor has escuchado mis plegarias😄

De verdad que Facundo es increíble con esto del Zen de Python

Special cases aren't special enough to break the rules.(Los casos espciales, no son los suficente especiales para romper las reglas), Osea que no podemos romper así como por capricho las correctas prácticas para usar Python.

El zen de python 😃

Más claro imposible. A seguir en modo Zen Python

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

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!

El ZEN de python son los principios fundamentales para poder escribir nuestro código de manera clara, precisa y sencilla 😄

Notas 😄
El Zen de Python.

• Fueron creados hace 20 años, por uno de los cofundadores de Python 🐍.
• ¿Qué es? Son los 20 principios de software que tiene Python para escribir nuestro código de manera correcta y precisa. 😄
• Para ver los 20 principios, hacemos import this. La lista completa:
  1. Beautiful is better than ugly.
  2. Explicit is better than implicit.
  3. Simple is better than complex.
  4. Complex is better than complicated.
  5. Flat is better than nested.
  6. Sparse is better than dense.
  7. Readability counts.
  8. Special cases aren’t special enough to break the rules.
  9. Although practicality beats purity.
  10. Errors should never pass silently.
  11. Unless explicitly silenced.
  12. In the face of ambiguity, refuse the temptation to guess.
  13. There should be one-- and preferably only one --obvious way to do it.
  14. Although that way may not be obvious at first unless you’re Dutch.
  15. Now is better than never.
  16. Although never is often better than right now.
  17. If the implementation is hard to explain, it’s a bad idea.
  18. If the implementation is easy to explain, it may be a good idea.
  19. Namespaces are one honking great idea – let’s do more of those!

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!

Qué es el Zen de python?

• Son esos 20 principios de software para desarrollar codigo, que van a permitir el entendimiento del mismo al momento de ser leidos por otras persoas.
  Cómo abrir el zen de python?
• Import this–> en la interfaz de py
  IMPORTANTE

1. Bello es mejor que feo
2. Explicito es mejor que implicito
3. simple es mejor que complejo
4. plano es mejor que anidado
5. los errores no deberian pasar silenciosamente
6. espaciado es mejor que denso
7. la legibilidad es importante

Les dejo un artículo que hice en el blog de Python Barranquilla sobre el Zen de Python.
Cualquier sugerencia o comentario es bien agradecida
https://pybaq.co/blog/el-zen-de-python-explicado/

No conocía el Zen de Python, lo que había aprendido sobre estilo y estructura fue a través de PEP pero que bonito es encontrar algo que te explique cómo deberías escribir buen código en unas cuantas líneas de texto. Como dicen, más claro ni el agua.

Strike first, strike hard, no mercy! #CobraKai

🐍 El Zen de Python nos permitirá escribir código de manera clara, precisa y sencilla.

Explicit is better than implicit (Explícito es mejor que implícito), Debido a que es buena práctica empezar a escribir un poco más, para la buena creación y explicación de nuestro código que simplemente dejar las cosas ambígüas

Existe un lenguaje de programación que es aún más bello que Python, Julia. Es una mezcla de Python pero con Numpy y Scipy de origen.

Son los 19 principios que tiene este lenguaje de programación poder escribir de manera precisa.

Para usar Python, en la CMD de Windows debemos escribir py , pero en un entorno tipo Linux, es python3

Para ver el zen de python usamos import this. This es un módulo oculto y secreto.

1. Bello es mejor que feo -> Python tiene la sintaxís más simple.
2. Explícito es mejor que implícito -> Siempre que podamos expresarnos en código para que el mismo se entienda mejor, vamos a hacerlo así.
3. Simple es mejor que complejo -> Si podemos resolver un problema en menos líneas de código y se entiende mejor, vamos por ese camino.
4. Complejo es mejor que complicado -> Si es necesario hacer las cosas complejas pero bien hechas, es mejor ese camino.
5. Plano es mejor que anidado -> Si tenemos muchos bloques de código, uno dentro de otro, la indentación será muy grande, esto lo debemos evitar.
6. Espaciado es mejor que denso -> Python nos obliga a hacer esto.
7. La legibilidad es importante -> Si podemos escribir código que se entienda mejor y que otras personas lo puedan entender, vamos por el buen camino.
8. Los casos especiales no son lo suficientemente especiales para romper las reglas -> Siempre que podamos respetar las reglas de Python, es mejor que lo hagamos así.
9. Sin embargo la practicidad le gana a la pureza -> Hay que tener un equilibro entre esta regla y la #8.
10. Los errores nunca deberían pasar silenciosamente -> Todo programador debe saber manejar errores
11. A menos que se silencien explícitamente -> Podemos hacer que los errores se silencien pero con consciencia.
12. Frente a la ambigüedad, evitar la tentación de adivinar -> Nuestro código debe tener solamente 1 interpretación.
13. Debería haber una, y preferiblemente solo una, manera obvia de hacerlo.
14. a pesar de que esa manera no sea obvia a menos que seas holandés (chiste del creador).
15. Ahora es mejor que nunca -> Si encontramos la solución hoy, no la dejes para mañana.
16. A pesar de que nunca es muchas veces mejorq que ahora mismo -> Si tenemos prisa, podemos hacer un mal código, es mejor dejarlo para después.
17. Si la implementación es difícil de explicar, es una mala idea. -> Si no podemos explicar nuestra idea, ni siquiera nostros mismos la entendemos.
18. Si la implementación es fácil de explicar, puede que sea una buena idea.
19. Los espacios de nombres son una gran idea, ¡tengamos más de esos! -> Tema avanzado de 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!

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!
Easter Egg

import this

The Zen of Python, by Tim Peters

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!

Hoy debo presentar avances de un proyecto al dueño de la empresa. Si no hubiese visto ese vídeo, creo que no habría analizado como he hecho el código de tal proyecto. Por fortuna, he llevado buenas prácticas y corregí algunas cosas. Definitivamente Python es mágico.

Comparto mis notas

Son los 20 principios de software mas imporantes que tiene Python para poder escribir nuestro codigo de la forma mas preciso. Tim Peters en 1999 fue el creador de este Zen. Se puede visualizar en el modo interactiva colocando import this, el cual es un modulo oculto.

1. Beautiful is better than ugly.

   El lenguaje es esticamente superior a cualquier otro. Si vamos a escribir codigo es mejor que sea de manera estica.

2. Explicit is better than implicit.

   Siempre que podamos extendernos para que otras personas puedan entender lo que estamos escribiendo, es mejor.

3. Simple is better than complex.

   Si tenemos una implementacion que ocupa pocas lineas de codigo y es entendible, es mejor elegir esta para resolver un problema antes que una que es mas complicada.

4. Complex is better than complicated.

   Si es necesario extenderse para que el programa se entienda, es mejor hacerlo complejo antes que simple pero complicado.

5. Flat is better than nested.

   El anidamiento es un problema comun en los lenguajes, sucede cuando colocamos un bloque debajo de otro bloque, la indentacion se hace mas grande y cada vez el codigo se corre a la derecha. Esto se puede solucionar.

6. Sparse is better than dense.

   Este principio es imposible de esquivar ya que Python obliga a tener una indentacion obligatoria antes de comenzar un bloque de codigo, equivalente a un TAB o 4 espacios.

7. Readability counts.

   Que nosotros y otros desarralladores puedan entender lo que escribimos es fundamental, para que todo pueda ser colaborativo en el futuro.

8. Special cases aren’t special enough to break the rules.

9. Although practicality beats purity.

   Nos vamos a encontrar en ocasiones donde queremos quebrar las reglas esteticas que nos da Python para querer las cosas de forma diferente, siempre que podamos mantener el codigo ordenado se debe hacer. Se debe de tener un equilibrio entre si queremos hacer las cosas de manera practica o pura.

10. Errors should never pass silently.

    Manejar los errores es un tema fundamental para poder ser un Ingeniero de Software.

11. Unless explicitly silenced.

    Como programador se puede hacer que un error pase de largo y nuestro codigo siga funcionando. Si este no se hace con criterio o sentido comun

12. In the face of ambiguity, refuse the temptation to guess.

    Si una pieza de codigo que en un contexto siginifica algo y en otro contexto significa otra cosa. Es mejor detenerse y analizar la solucion, porque nuestro codigo deberia tener una interpretacion.

13. There should be one-- and preferably only one --obvious way to do it.

14. Although that way may not be obvious at first unless you’re Dutch.

    Esto hace referencia al creador de Python, Guido Van Rossem, que lograba encontrar las soluciones de manera precisa.

15. Now is better than never.

    Si podemos desarrollar la solucion que tenemos para un problema en este momento, es mejor hacerlo cuanto antes.

16. Although never is often better than right now.

    Si por querer las cosas inmediatamente y tenemos poco tiempo, talvez si es mejor dejarlo para despues.

17. If the implementation is hard to explain, it’s a bad idea.

18. If the implementation is easy to explain, it may be a good idea.

    Si nosotros entendemos nuestro codigo, debemos ser capaces de expresarlo a otras personas y guiarlos paso a paso. Si no somos capaces de explicar los conceptos, significa que ni nosotros mismos lo entendemos.

19. Namespaces are one honking great idea – let’s do more of those!

    Viene de namespaces… 🔜

Principios del software
1999 - import this
Más lineas pero más explícito.
Los algoritnos simples son mejor que los complejos.
Hacer los algoritmos complejos para que no sean complicados.
No hacer anidaciones largas.
Hacerlo todo limpio.
Que todos puedan leer mi código.
La practicidad gana a la pureza.
Manejar los errores, blindar el código.
Nada es ambiguo.
Ahora es mejor que nunca.
La implementación deberá ser fácil de explicar.
Espaciado en los nombre.

El Zen de Python: Beautiful is better than ugly (Bello es mejor que feo), refiriéndose a la calidad estética que tenemos con Python debido a su sintaxis tan simple.

Errors should never pass silently.(Los errores nunca deberían pasar silenciosamente) Ese tipo de casos en los que pones la basura debajo de la alfombra, nunca deberían pasar y si lo haces, al menos que no sea a escondidas, sino una desición unánime

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. (Si la implementación es difícil de explicar, es una mala idea, Si la implementación es fácil de explicar, es tal vez una buena idea) Mantenlo simple y recuerda que si no eres capaz de explicarlo, no lo entiendes del todo bien.

The Zen of Python, by Tim Peters

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!

Tener principios tan sólidos en un lenguaje de programación, hace que sea mas fácil programarlo y entenderlo, creo que hasta hoy python es un lenguaje sólido por estos principios.

no encontre mi antigua terminal, creo que la cambie por una que usa ubuntu en windows, pero me va bien para el curso je

The Zen of Python, by Tim Peters

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!

me gustó mucho “simple es mejor que complejo” y “si la implementación es difícil de explicar es mala idea”, creo que en toda área de la vida aplica: “si no sabes explicar algo de forma sencilla, quiere decir que no lo entendiste lo bastante bien” Albert Einstein.

Bello es mejor que feo.
explixito es mejor que implicito
simple es mejor que complejo.
complejo es mejor que complicado
plano es mejor que anidado
espaciado es mejor que denso
Legibilidad es importante.

Equilibiro entre practicidad y Legibilidad debe de estar presente en el código

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!

Aprender un programa no es solo escribir instrucciones, es saber hacerlo de una manera estética. Que buena introducción.

el zen de python por tim petters

The Zen of Python, by Tim Peters

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!

Explica ciertos veinte principios de software más importantes de Python que nos ayuda a escribir nuestro código de manera evidente, sencilla y precisa. Creados por Tim Peters.‎

‎

‎
Bello es mejor que feo

Muchas veces evitamos preocuparnos por el entendimiento de nuestro código; pero:

• Crear con Python es crear preciso, limpio y legible código para todos

‎

Explícito es mejor que implícito

Siempre que podamos, extender o detallar nuestro código volverá fácil la lectura de este

• Debemos de evitar la ambigüedad
• Debemos de asegurar la claridad

‎

Simple es mejor que complejo

Trata de optar por simplificar pero de manera entendible las líneas del código

• Pero en esta pauta es imprescindible conocer el límite de lo simple.

‎

Complejo es mejor que complicado

La simplicidad en otros casos no es aplicada porque es necesario más tecnicismo en estos

• Complejo != ilegibilidad
• Lo complejo puede ser sencillo aplicándolo adecuadamente

‎

Plano es mejor que anidado:

Un problema común en programación es dónde un bloque de código es hijo de otro.

• Esto deforma la estética que nos provee Python en su identación
• Hay técnicas con la que podemos obviar la anidación de bloques

‎

Espaciado es mejor que denso:

La sangría o identación está incluido en la manera de cómo Python trata el código

• Siempre cuatro 4 o un tab antes de un bloque de código

‎

La legibilidad es importante:

Que todos puedan entender el código que hemos escrito es fundamental:

• Esto induce una mejor colaboración y desarrollo de un trabajo o proyecto

‎

La practicidad le gana a la pureza

Los casos especiales son insuficientemente especiales para romper las reglas en Python

• Siempre que podamos, debemos seguir la estética pythonista, pero:

• ¿Y sí esto interfiere en la legibilidad?

  Si esta pureza en el código interfiere en la legibilidad de este: debemos de optar por la practicidad.

‎

Los errores nunca deberían pasar silenciosamente

Dominar el manejo de los errores es lo fundamental en nuestra trayectoria, pero:

• Es una posibilidad en base a criterio común silenciar ciertos errores que no interfieren en el avance del proyecto

‎

Frente a la ambigüedad, evitar la tentación de adivinar:

Si tenemos cierta línea de código que logra significar distintas cosas, debemos:

• Reformular su estructura lógica pues este tiene un solo significado inmutable.

‎

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.

• Esta última refiere al creador de Python (Guido van Rossum)
• Nos indica si de ser posible, deberíamos imitar su actitud ingeniosa

‎

Ahora es mejor que nunca:

Si podemos resolver los problemas o obstáculos en nuestro código:

• No debemos de procrastinar tal resolución del problema.

‎

A pesar de que nunca es muchas veces mejor que ahora mismo:

Si queremos resolver los problemas de código de forma rápida:

• Es mejor procrastinar para obviar realizar un código defectuoso

‎

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 podemos explicar a detalle nuestra implementación, es una buena idea.
• Sino podemos hacerlo significa que ni nosotros entendemos la implementación

‎

Los namespaces son una gran idea:

Son clave para evitar que los nombres de un módulo o ámbito entren en conflicto con los nombres de otro.

• Deben crearse solo para evitar conflictos de nombres y no para agregar una categorización innecesaria

The Zen of Python, by Tim Peters

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!

The Zen of Python, by Tim Peters

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!

El tema de la documentación es extremadamente importante y es una gran parte de lo requerido en el software para mantener un ciclo de vida activo para este. Es muy común cometer el error de no generar anotaciones precisas en el código y que para variar, haya mala documentación.

Considero darle mucha importancia al Zen de Python, ya que de esta manera logramos mantener su belleza, así seamos principiantes 🤓💚💪

genial facundo como profesor que es muy motivador

Previamente había leído este articulo

https://pythondiario.com/2018/06/el-zen-de-python.html

El Zen de Python es acorde al Zen de estas clases.

Algunos principios de El Zen de Python parecen principios
de vida, como “Although never is often better than right now.”

Es mejor ahora…:

Python Zen ❤️

La filosofía

Super interesante, siento que este curso va a estar de lujo!!!

Me encanto el Zen 😃

El Zen de Python es algo que debemos tener claro para todo tipo de lenguaje de programacion, no se imaginan la cantidad de gente que no conoce eso 😕

me gusto mucho la documentación, creo que ahora podre hacer código mas bonito y mas importante, mas legible

woooo, esto esta genial

Python es el mejor lenguaje del mundo. Su practicidad y sencillez lo hacen uno de los más legibles, más bonitos y más fáciles de aprender.

Que sea esteticamente superior es, para mi, una opinion subjetiva.

Ese Zen de Python parece una lección de vida estilo Sr. Miyagi 🧐

Algo curiosos que pienso es que, a pesar de llamarse “Zen de python”, bien podrían aplicarse en cualquier otro aspecto del desarrollo de software.

I think I learned a lot of English today.
Here you are the Zen of Python, so can check it.

The Zen of Python, by Tim Peters

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!

lest be zen

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!

Me quedo con que es mejor hacer las cosas simples, practicas y bonitas que cosas rigidas y poco practicas

El Zen de Python:

1. Beautiful is better than ugly.
   –> Bello es mejor que feo
2. Explicit is better than implicit.
   –> Explicito es mejor que implicito
3. Simple is better than complex.
   –> simple es mejor que complejo
4. Complex is better than complicated.
   –> Complejo es mejor que complicado
5. Flat is better than nested.
   –> Plano es mejor que anidado
6. Sparse is better than dense.
   –> Espaciado es mejor que denso
7. Readability counts.
   –> La legibilidad es importante
8. Special cases aren’t special enough to break the rules.
   –> los casos especiales no son lo sufuente especiales como para romper las reglas
9. Although practicality beats purity.
   –> Sin embargo la practicidad le gano a la pureza.
10. Errors should never pass silently.
    –> Los errores nunca deberían pasar silenciosamente
11. Unless explicitly silenced.
    –> a menos que se silencien explicitamente.
12. In the face of ambiguity, refuse the temptation to guess.
    –> Fren te a la ambugüedad, evitar la tentación de adivinar.
13. There should be one-- and preferably only one --obvious way to do it.
    –> Debería haber una y preferiblemente solo una manera obvia de hacerlo.
14. Although that way may not be obvious at first unless you’re Dutch.
    –> A pesar de que esa manera no sea obvia a menos que seas holandés
15. Now is better than never.
    –> Ahora es mejor que nunca
16. Although never is often better than right now.
    –> A pesar de que nunca es mucha veces mejor que ahora mismo
17. If the implementation is hard to explain, it’s a bad idea.
    –> Si la implementación es dificil de explicar es una mala idea.
18. If the implementation is easy to explain, it may be a good idea.
    –> Si la implementación es facil de explicar, puede que sea buena idea.
19. Namespaces are one honking great idea – let’s do more of those!
    –> Los espacios de nombres son una gran idea, ¡tengamos mas de eso!

The Zen of Python, by Tim Peters

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!

Cada día se aprende más!
#NuncaParesDeAprender💚

Excelente y como aporte https://pybaq.co/blog/el-zen-de-python-explicado/

Me gusta el Zen de Python, creo que lo voy a usar algunos también para mi día a día🥰

Me tome mi rato tomando esta clase, te ayuda a armar el setup correcto en tu mente para programar

parecen los 20 mandamientos del lenguaje python

Entendido

Que genial!

muy bien iniciar a elevar de nivel, muchos temas veo que no domino al cien

Genial que da el curso Facundo.

Muy buenas frases y consejos.

El curso más esperado por toda Latinoamérica unida

Buena clase!

Me encanta el tono espiritual que le pone a la clase 😁

Python's Zen

Nunca mejor explicado.

Otra:

EAFP: “it’s easier to ask for forgiveness than permission”.

Although never is often better than *right* now.(Aunque nunca es casi siempre, mejor que ahora mismo) Si vas a hacer las cosas mal por el afán, mejor no hagas nada.

Readability counts.(La legibilidad cuenta, o es mportante) Tenemos que tener todo muy bien escrito para una buena compresión del código.

import this

El principio 20 debería de ser:
“Hacer código es fácil, pensar es difícil”