versión color - PET: Python Entre Todos - Python Argentina

15 Clueless
Clueless
No Clueless (http://xkcd.com/676/)
El chiste anterior muestra de una manera irónica y cínica que sucede cuando vemos una solución informática sin un correcto
nivel de clueless, pasando por cada nivel de abstracción disponible en el sistema.
Así el principio de clueless se basa en un idea muy simples: La ignorancia es un beneficio; la cual nos ayuda a enforcarnos
en el problema a solucionar y no nos dispersa en rediseños de ruedas, que en general ya cuentan con soluciones bien
realizadas en librerías ya existentes que vamos a usar sin que nos importe conocer su funcionamiento interno.
Cabe aclarar que es una idea que para quedarse (y es en cierta medida lo que provee las n capas de abstracción sobre el
hardware que hoy tenemos), y que NO significa “no saber”, sino, no preocuparse en lo que es el core de de tu programa y no
funcionalidades ya existentes.
Como último detalle aclaramos que Python es altamente “clueless” ya que nos evita pensar en cosas de bajo nivel que otros
lenguajes no.
Zen Vs. Zen
Las librerías al menos contradicen de alguna manera el “zen” de Python en los siguientes puntos:
• Explicit is better than implicit: Ya que ocultamos cierta funcionalidad adentro de un tipo de “caja negra”.
• Flat is better than nested: La funcionalidad se encuentra anidada en la “caja negra” antes mencionada.
• Special cases aren’t special enough to break the rules: Si consideramos a Python pelado como la forma “común” de
hacer las cosas, utilizar una solución de terceros sería no utilizar la forma común, entonces estaríamos frente a un caso
especial donde no utilizamos las reglas comunes de solución de problemas.
• There should be one— and preferably only one —obvious way to do it: Muchas librerías que resuelven un mismo
problema existen (django, web2py, bottle, etc) por lo cual no hay una sola forma evidente de hacer las cosas.
¿Por qué es importante recordar estos puntos?, sencillamente porque ayudan a tomar decisiones de qué librería usar para cada
problema, es importante asumir que cuando nos decidimos a utilizar una librería (o diseñarla) estamos atando nuestro curso de
trabajo futuro a una forma no estándar, que es lo que intenta prevernirnos el Zen de Python. Así que pensar en utilizar o
diseñar una librería es un punto bastante crítico a tener en cuenta; así como también es importante recordar estos (otros)
aformismos también presentes en el Zen que evitan que caigamos en:
• Although practicality beats purity: Es mucho mas práctico utilizar una librería que empezar a escribir todo desde cero.
• Namespaces are one honking great idea — let’s do more of those! Las librerías son los espacios de nombres mas
cómodos de utilizar ya que se mantienen totalmente ajenos a nuestro desarollo
Así que dado que hay cosas contradictorias en las decisiones de diseños de API’s y librerías voy a continuar dando unos consejos
útiles a la hora de tomar la decisión de encarar un proyecto de este tipo para que se ajuste lo mejor posible a los principios del
“estandaridad” de uso que plantea el Zen de Python.
Consejos
Exponer solo los métodos necesarios: Tratar de exponer muchos métodos, clases, funciones y variables públicos puede
confundir al usuario de tu API. Tratar de mantener las llamadas públicas justas, que sirvan para dar la funcionalidad de la
librería y no mucho mas. Tampoco hay que excederse con esto ya que si dejamos muy rígida nuestra librería, por la falta de
comportamiento público puede que en algunos casos se vuelva inútil. En definitiva, debería cumplirse esto:
>>> len([n for n in dir(obj) if not n.startswith("_")])
(numero pequeño)
Python Entre Todos (número 5, Marzo 2012) — http://revista.python.org.ar