UNIVERSIDAD AUTÓNOMA

GABRIEL RENE MORENO

FACULTAD DE INGENIERÍA Y CIENCIAS DE LA
COMPUTACIÓN Y TELECOMUNICACIONES

PROGRAMACIÓN I

TAREA I
ZEN DE PHYTON
DOCENTE :
Ing. Edwin Vargas Yapura

MATERIA:
Programación I – INF 120 SD

GRUPO: 12

PORCENTAJE TERMINADO

Investigación: 70%

INTEGRANTES DT HG HI EVALUACION

Gabriel Copa Umacacho 1 2 3 90%

Marion Mahonri Casasola Orellana 2 2 4 90%

Yimmi Noel Choque Nina 2 1 4 90%

Richard Camargo Guzman 2 1 2 90%

Sejas Miranda Isabel 1 1 2 60%

Fecha de Presentación: Viernes, 2 de Diciembre del 2022

Fecha Presentada: Viernes, 2 de Diciembre del 2022

Días de Retraso: 0
 COMENTARIO
Con el siguiente trabajo que hemos realizado hemos entendido que se puede llamar
al lenguaje Python como muy sencillo, que deja enfocarse en el problema, ayuda a
hacer los código más simple, limpio, legible, esto también pudimos percibir en los
comentarios de los compañeros y el docente, nos damos cuenta que responde de
una manera muy similar, hay un patrón por ahí, esto se debe al resultado de la forma
en la que ha evolucionado el lenguaje y la importancia que se le ha dado a ciertos
principios fundamentales que han guiado esa evolución.

Con este trabajo también entendimos por qué el ingeniero nos recomienda tener
una mejor presentación en nuestro código, ósea que nuestro código fuera más
PYTHÓNICO, así utilizando y aplicando esos principios del ZEN PHYTON.
ZEN PHYTON

El Zen de Python es una colección de 20 PRINCIPIOS DE SOFTWARE que influyen

en el diseño del Lenguaje de Programación Python, de los cuales 19 fueron escritos
por TIM PETERS en 1999.

Este documento de nombre PEP 20 - “Import This” es TEXTO CORTO pero tan

lleno de sabiduría que engloba a toda la filosofía del lenguaje vamos a explorar

cada uno de los principios en este documento en nuestro idioma y aprender a

aplicarlos cuando estemos escribiendo código, además cuando estás diseñando

algún producto e incluso al interactuar con la sociedad.

PRINCIPIOS

bello es mejor que feo.

Comenzamos con uno de los principios más objetivos del centro y es que, la
belleza está en los ojos de quien mira es muy difícil traducir algo tan subjetivo como
a la belleza al mundo del software que está lleno de elementos, objetivos pero bueno
tal vez podamos acordar algo cuando vemos algo que personalmente consideramos
bello normalmente nos genera alegría, asombro. con un propósito distinto por
supuesto exactamente si podemos encontrar este tipo de contrastes en el mundo de
la arquitectura de software de los procesos de integración continua e inclusive en el
código mismo entonces si realmente mantener una base de código que
consideramos bella nos promete que podamos ser más felices pues debería ser
razón suficiente para valorar la belleza en cada línea que escribimos en cada
producto que diseñamos claro que la belleza no lo es todo inclusive a veces
viene con un costo añadido de mantenimiento.
Ejemplo

EXPLICITÓ ES MEJOR QUE IMPLÍCITO

Este principio es muy sencillo, se trata de reducir ambigüedad (que puede

entenderse de varios modos o admitir distintas interpretaciones) de reducir
incertidumbre, veamos un pequeño ejemplo de código.
Funcion 1 Funcion 2
// calcula si es mayor o menor de edad
d = int(input( ))
edad = int(input("Escribe tu edad: ")) if d >= 18:
if edad >= 18: print() else:
print("Mayor de edad") print( )
else:
print("Menor de edad")

Vemos estas dos funciones que queremos entender qué es lo que hace, entonces
puedes ver una función calcular si es mayor o menor de edad, La Funcion 1 pide
edad el cual detalle que escriba la edad procesa y devuelve si es mayor de edad o
menor de edad, la Funcion 2 parece que calcular toma algunos datos que se los
manda a la función de procesar o hará con ellos para obtener después un el resultado
va más o menos podemos dar una idea de qué es lo que hace este código sin
embargo no se está ocultando cosas hay muchas cosas implícitas en este código que
no nos dan la información completa.
SIMPLE ES MEJOR QUE COMPLEJO, COMPLEJO ES MEJOR QUE
COMPLICADO

En programación si empezamos con elementos que no son sencillos, que no

están bien definidos, no tienen un propósito claros, que son como son
complicados, en sí pues los empezamos a combinar para crear algo más grande
vamos a terminar con que no sabemos ni dónde empieza y dónde termina y que
si queremos modificar una parte de en medio pues no perdemos, porque simplemente
no fue diseñado para eso, entonces aquí la clave es comenzar con esos elementos
simples, manejables y combinarlos de tal manera que lo vamos a hacer cosas tan
complejas como necesitemos como desarrollador de software.Ejemplo :

Simple

def menor5( a, b, c, d, e):

return menor(menor(a,b),menor(menor(c,d),e))

Complejo

def menor5( a, b, c, d, e):

if a < b and a < c and a < d and a < e : return a

if b < a and b < c and b < d and b < e : return b

if c < a and c < b and c < d and c < e : return c

if d < a and d < b and d < c and d < e : return d

else : return e

PLANO ES MEJOR QUE ANIDADO

Hemos aprendido la palabra de anidado hay dos principales en los que las cosas
anidadas se manifiestan y causan problemas, vamos a verlas cuando escuchamos
condiciones anidadas, ciclos anidados, se refiere que ponemos una condición dentro
de otra un ciclo dentro de otro una condición dentro de ellos y asi.

Ahora cuando hacemos esto que sucede pues cada vez que anidamos algo estamos
agregando un nuevo camino independiente que puede tomar el código existen
medidas formales de medir esto como el índice de complejidad ciclo matemática de
main que es muy sencillo realmente es cuenta cuántos caminos independientes hay
en el código y eso te da una medida de complejidad porque esto es importante pues
porque cuando un desarrollador llega a uno de esos caminos y hace un cambio entre
más caminos haya pues va a ser más difícil para él considerar como los cambios que
está haciendo en uno de esos caminos impactan al resto de los caminos entonces
pues tratemos de no anidar tantas tantos niveles de crear tantos caminos
independientes tratemos de mantenerlos de una manera más plana para evitar estos
problemas y reducir la complejidad tener funciones mucho más claras otro lugar
donde esto se manifiesta sin jerarquías.

ESCASO (ESPARCIDA) ES MEJOR QUE DENSO

Aquí la traducción literal a español de escaso no me parece suficiente piensa en algo

entre escaso y esparcido vamos a tratar de entenderlo así, entonces donde podemos
encontrar densidad al programar en una función con muchas líneas puede ser densa
un archivo con muchas clases, demasiadas funciones va a ser denso lo mismo un
paquete con demasiados módulos demasiados archivos etc., entonces qué hacemos
ante esta densidad pues tratar de reorganizar de esparcir mejor el código para evitar
esa lluvia de box que ya se ve por venir LA LEGIBILIDAD ES IMPORTANTE.
Algo muy claro el código de alto nivel, es para humanos no es para computadoras
entonces hablemos de niveles en los que podemos considerar el código correcto un
código que consideremos correcto como base fundamental pues tiene que hacer lo
que debe de hacer no ahora este nivel es más que suficiente para el procesador al
procesador no le interesa nuestros bonitos nombres de variables ni nuestra
modularidad entonces siempre y cuando el código haga lo que debe de hacer el
procesador lo pueda ejecutar y obtengamos una respuesta correcta pues todo está
bien pero vamos a ver más niveles en los que el código puede ser todavía mejor el
siguiente nivel sería que lo haga de forma evidente no digo para el procesador para
el procesador ya que damos que eso no le interesa pero a un humano si le interesa
que lo que hace el código lo haga de forma evidente y me refiero a control de flujo
claro buenos nombres de variables buenos nombres de funciones que sea explícito
en fin e inclusive ya el siguiente nivel es que nos explique por qué que nos diga el
contexto de cuando estabas haciendo ese cambio que era lo que estaba sucediendo
que estabas tratando de arreglar porque la persona que venga en seis meses o un
año a arreglar algo en este código o a agregar una nueva funcionalidad no va a tener
el contexto que tú tenías cuando lo hiciste y pues muchas veces esa persona
terminamos siendo nosotros mismos, escribo código en realidad deberías ser como
dejándole a un humano un documento que dice exactamente lo que quiero que haga
la computadora y por qué y claro que es muy divertido jugar con el código y pues
tratar de usar la menor cantidad de caracteres posibles la menor cantidad de
sentencias posibles pero si tratas de escribir siempre código legible va a ser mucho
más fácil cobrarlas cuando hacerlo sea importante.
LOS CASOS ESPECIALES NO SON SUFICIENTEMENTE ESPECIALES PARA
ROMPER LAS REGLAS - SIN EMBARGO LA PRACTICIDAD LE GANA A LA
PUREZA.

Tener un caso especial vamos a dejar a un lado todas las reglas que teníamos por
algo existía, por el otro lado pues si tenemos un problema que tenemos que resolver
pues no vamos a ser puristas irnos completamente al otro extremo y no resolverlo
porque había reglas entonces qué hacer pues bueno adoptar la prácticabilidad y
cómo hacemos eso pues bueno encontramos una solución que tal vez no va a estar
100% a favor de lo que decían las reglas pero para hacer esta solución práctica
necesitamos entender esas reglas muy bien entender por qué existían entender qué
es lo que tratan de proteger y entonces así podemos documentar bien nuestra
solución entender cuáles son las ventajas y el costo y el beneficio de lo que estamos
haciendo mejor ejemplo de esto no podría haber más que el trabajo desde casa o el
tener paicone desde casa los organizadores definitivamente siguieron el principio de
prácticabilidad y gracias a eso estamos aquí
LOS ERRORES NUNCA DEBERÍAN PASAR SILENCIOSAMENTE.

A MENOS QUE SE SILENCIEN EXPLÍCITAMENTE.

(ERRORES RUIDOSOS, A CONSIDERACIONES)

Los errores nunca deberían pasar silenciosamente a menos que sean explícitamente
entonces queremos para nuestro código, no queremos que en nuestro código, las
situaciones de error que sucedan se queden sin solucionar, al contrario queremos
que sean ruidosas que nos avisen que algo malo está pasando y que no dejemos
pasar esos errores.

FRENTE A LA AMBIGÜEDAD, EVITAR LA TENTACIÓN DE ADIVINAR.

“NO ADIVINAR”

Ante la ambigüedad rehúsa la tentación de adivinar imagínate que estás haciendo

una estructura de datos o una nueva funcionalidad de la librería estándar y te das
cuenta de que en cierto punto de tu implementación no estás seguro de cuál es la
intención del usuario cuando llegas a esa condición entonces pues qué haces algunos
lenguajes por ejemplo te permiten comparar enteros con strings y eso qué quiere
decir pues por debajo el interprete o el compilador tienen que tomar una decisión y
esa decisión pues puede que sea no sé convertir el string en entero con palabras
referencias piensan en python esto no sucede en el ideal para python es si encontré
ambigüedad voy a decidir no adivinar ante ella y entonces ahí te da un error lo mismo
puedes hacer para el código que estés escribiendo cuando estés implementando un
programa lo que sea si tú no tienes información suficiente para des ambigua la
intención de tu usuario si es un excelente momento para lanzar una excepción.

DEBERÍA HABER UNA, Y PREFERIBLEMENTE SOLO UNA, MANERA OBVIA DE

HACERLO.

A PESAR DE QUE ESO NO SEA OBVIO AL PRINCIPIO A MENOS QUE SEAS

HOLANDÉS.

Una Manera Obvia De Hacerlo

Debería haber una y solo preferiblemente, solo una manera obvia de hacerlo, aunque
esa manera puede no ser obvia al principio a menos que seas holandés, este es otro
de los principios subjetivos del Zen, porque pues bueno que es obvio y que no es
obvio incluso aquí Tim el autor hace una pequeña broma hacia cuidó el creador de
payton porque Widow es holandés entonces para widow y era obvias las maneras de
hacerlo y bueno me estás diciendo que hay una forma obvia de escribir Python, me
gustaría decir que si ahora este problema es mucho más allá de que hay muchos
lenguajes que tienen este problema incluso más arraigado por ejemplo pero pero
tiene un problema de densidad tiene tantas maneras similares de expresar la misma
cosa que se crea una explosión combinatoria de maneras de expresar lo mismo y por
lo tanto que simplemente no hay una forma obvia de escribir pero ruido no quería esto
para país la visión para python era tener sólo unas cuantas cosas unas cuantas
maneras de escribir la misma cosa pero que de esas maneras sólo una fuera la
elección obvia ahora esto es muy muy difícil de lograr sobre todo con un lenguaje que
está en constante evolución que lleva en evolución tantos años y que incluso se
siguen aumentando nuevas maneras de expresar cosas nueva funcionalidad

AHORA ES MEJOR QUE NUNCA.

A PESAR DE QUE NUNCA ES MUCHAS VECES MEJOR QUE *AHORA* MISMO.

Ahora es mejor que nunca aunque nunca suele ser mejor que justo ahora

Esa optimización que crees que vas a necesitar en dos meses y esa pequeña
decoración que le estás poniendo a tu código por si las dudas no las vas a necesitar
lo que nos invita este principio del zen es a evaluar cuál es el momento correcto de
implementar algo entonces bueno de entrada lo vas a necesitar o no lo vas a necesitar
si lo si no lo vas a necesitar pues cuando es la mejor el mejor momento de
implementarlo simplemente nunca pero si lo vas a necesitar y lo haces justo ahora
pues lo podrías hacer con calidad, simple, explícito

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.

Facil de explicar

Si la implementación es difícil de explicar es una mala idea, si la implementación es

fácil de explicar puede ser que sea buena idea hay una manera muy sencilla de
darnos cuenta si entendemos algo o no y es explicándoselo a alguien en voz alta tal
vez han escuchado sobre ROBERT DOT DE BOOKING que simplemente consiste
en explicarle a un patito de hule línea por línea qué es lo que hace tu código para
encontrar un problema lo mejor de todo es que funciona y porque funciona pues
porque cuando ponemos nuestras ideas en palabras eso nos ayuda a pensar más
claro nos nos ayuda a realmente darnos cuenta si entendemos algo o no cuando esas
palabras son complicadas nos llevan por una explicación rebuscada probablemente
estamos explicando algo que es una mala idea de una implementación o simplemente
es una idea incompleta en cambio cuando estamos explicando lo de forma fluida
natural pues lo más probable es que esa implementación sea una buena idea.

LOS ESPACIOS DE NOMBRE SON UNA IDEA GENIAL, ¡HAGAMOS MÁS DE

ELLOS.!

Los espacios de nombres simplemente son, lo que nos permite utilizar definiciones
idénticas en diferentes contextos que significan diferentes cosas pensemos una
variable que se llama igual que una función o que se llama igual que un módulo el
intérprete no se confunde entre estos entre estas definiciones porque cada uno está
en un contexto distinto entonces está en un espacio de nombre diferente piensa por
ejemplo en un teclado no es lo mismo cuando tú oprime es una tecla de una letra que
si la oprime es mientras que presionas alto shift entonces independientemente de lo
que haga en el hardware del teclado pues al aplicar estos modificadores tú estás
cambiando el contexto de la letra que estás presionando lo que estás haciendo es
cambiar ese espacio de nombre cierto y por lo tanto obtienes un resultado distinto.
CONCLUSIÓN

Como conclusión y aprendizaje de los principios en el Zen Phyton nos sirven de guía
para todas las personas de alguna manera y contribuyen al lenguaje al escribir el
código mas “bello, explicito, simple, complejo, plano, esparcido, legible, regla de
practicalidad, errores ruidosos, no adivinar, obvio, ahora nunca, fácil de
explicar, espacios de nombre,” esta es la esencia de payton estos son los principios
que al seguirlos hacen que tu código sea pythonyco.
VOCABULARIO

Phytonico: El código que siga los principios de Python

Tim Peters: Tim Peters es un desarrollador de software estadounidense conocido

por la creación del algoritmo de ordenación híbrido Timsort y por sus importantes
contribuciones al lenguaje de programación Python y su implementación original
CPython.

Indentación: Es un anglicismo de uso común en informática; Este término significa

mover un bloque de texto hacia la derecha insertando espacios o tabuladores.

Sangría: Es la distancia del margen de pagina o borde derecho o izquierdo.

Box: Puede almacenar cualquier tipo de archivo en línea y acceder a él fácilmente

desde su computadora.

Ambigüedad: La ambigüedad es la cualidad de aquel lenguaje “que puede

entenderse de varios modos o admitir distintas interpretaciones y dar, por
consiguiente, motivo a dudas, incertidumbre o confusión”

Bibliografía https://elpythonista.com/zen-de-python

https://es.wikipedia.org/wiki/Zen_de_Python

https://es.wikipedia.org/wiki/Python

https://peps.python.org/pep-0020/