Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Reflexiones en el diseño de librerías       PyCon Argentina - Junin, Bs. As. 24/09/2011
Quien cuerno soy?Juan B Cabral.       • La UTN dice que soy ingeniero.       • Edito la revista PET (http://revista.python...
Start    • La charla no trata estrictamente de Python.    • Mucho de esto esta sacado de Java (y su horrible forma de obli...
Librerías    • Las usamos para resolver problemas comunes.    • Sabemos que hacen pero no como lo hacen.    • Nos da un su...
API VS SPIAPI:       • Es la interfaz de un programa con el mundo.       • The API is the description of object... that yo...
No CluelessNadie sabe todo lo necesario para volar un avión.                               PyCon Argentina - Junin, Bs. As...
Clueless    • La ignorancia es un beneficio.    • Disminuyen el rediseño de la rueda 4.0    • Nos ayudan a enfocar en un p...
Zen Vs. Zen    • Las librerias almenos contradicen de alguna manera el "zen" de python:             • Explicit is better t...
Y...Como no me da la cara para decir "esta es la posta"; agrupe el resto de la charla en una sucesión deconsejos.         ...
Consejo: API (PROPIAMENTE HABLANDO)   • Exponer solo los métodos necesarios   • Tamaño de un API:     >>> len([n for n in ...
Consejo: API (PROPIAMENTE HABLANDO) 2 • No exponer jerarquías profundas: No es lo mismo diseñar para la API que para reusa...
Consejo: Cooperación con otras APIs    • Compatibilidad con las pilas.    • Seguir la PEP 8.    • Ojo con retornar objetos...
Consejo: Mis tipos, tus tipos    • De preferencia NO exponer objetos propios como resultados de operaciones.    • Librería...
Consejo: Tipos    • Los controles de tipos deben hacerse en el nivel de APIS    • Los Controles de tipos llevan tiempo.   ...
Consejo: Errores    • Llamamos errores a algo inmanejable por nuestra librería.    • Los errores se solucionan lo mas temp...
Consejo: Inmutabilidad Rulz!    • Si van a definir objetos intentar que sean inmutables (aumenta bastante laestabilidad de...
Consejo: Diseño   • Siempre planeen primero la funcionalidad.   • TDD.   • Primero el controller (MVC).   • Plantear inici...
Consejo: PortandoLo importante es       • Facilitar a la vida a los desarrolladores python:                • Respetar pep8...
Consejos: Publicación    • No publiquen sin tests.    • TDD se merece una oportunidad.    • Publiquen de manera comunes a ...
Consejos: Finales    • Hacer que nuestras cosas internas cumplan muchas de las cosas que dijimos.    • Las APIs simétricas...
¿Preguntas?   • Charlas:            • http://bitbucket.org/leliel12/talks   • Contacto:             • Juan B Cabral       ...
Upcoming SlideShare
Loading in …5
×

LibFree or Die Hard

1,394 views

Published on

  • Be the first to comment

  • Be the first to like this

LibFree or Die Hard

  1. 1. Reflexiones en el diseño de librerías PyCon Argentina - Junin, Bs. As. 24/09/2011
  2. 2. Quien cuerno soy?Juan B Cabral. • La UTN dice que soy ingeniero. • Edito la revista PET (http://revista.python.org.ar/) • Soy becario investigador en bioinformatica. • Me interesa la medición de la información desde un punto de vista científico. • Mi alineación es: Legal Malvado • Fumo Pipa (No fumo cigarrillos) • Me gusta el buen whisky. PyCon Argentina - Junin, Bs. As. 24/09/2011
  3. 3. Start • La charla no trata estrictamente de Python. • Mucho de esto esta sacado de Java (y su horrible forma de obligarte a hacer cosas feas) • Java sirve para algo: not(Te enseña como hacer cosas feas) • Surge como una duda personal de como saber si lo que hago esta bien. (Un api malo no deja de funcionar, solo es malo) • Recomiendo un libro: Practical API Design Mucha de mi charla se basa en este libro. PyCon Argentina - Junin, Bs. As. 24/09/2011
  4. 4. Librerías • Las usamos para resolver problemas comunes. • Sabemos que hacen pero no como lo hacen. • Nos da un suficiente nivel de "desconocimiento" (clueless). • Accedemos a través de sus APIS (asi que la charla se centra en eso). • Una buena API tiene un "correcto nivel" de "clueless". PyCon Argentina - Junin, Bs. As. 24/09/2011
  5. 5. API VS SPIAPI: • Es la interfaz de un programa con el mundo. • The API is the description of object... that you call and use to achieve a goal and • Un coso externo le pide algo a nuestro programa y luego el coso recupera el control.SPI: • The SPI is the description of object... that you extend and implement to achieve a goal • API subset. • Es la interfaz de un programa con un plugin. • Nuestro programa le pide algo a un coso externo y luego nuestro programa recupera el control. PyCon Argentina - Junin, Bs. As. 24/09/2011
  6. 6. No CluelessNadie sabe todo lo necesario para volar un avión. PyCon Argentina - Junin, Bs. As. 24/09/2011
  7. 7. Clueless • La ignorancia es un beneficio. • Disminuyen el rediseño de la rueda 4.0 • Nos ayudan a enfocar en un problema. • Esta para quedarse. • No significa "no saber". • Python es altamente "clueless". PyCon Argentina - Junin, Bs. As. 24/09/2011
  8. 8. Zen Vs. Zen • Las librerias almenos contradicen de alguna manera el "zen" de python: • Explicit is better than implicit. • Flat is better than nested. • Special cases arent special enough to break the rules. • There should be one-- and preferably only one --obvious way to do it. • Recordar: • Although practicality beats purity. • Namespaces are one honking great idea -- lets do more of those! PyCon Argentina - Junin, Bs. As. 24/09/2011
  9. 9. Y...Como no me da la cara para decir "esta es la posta"; agrupe el resto de la charla en una sucesión deconsejos. PyCon Argentina - Junin, Bs. As. 24/09/2011
  10. 10. Consejo: API (PROPIAMENTE HABLANDO) • Exponer solo los métodos necesarios • Tamaño de un API: >>> len([n for n in dir(obj) if not n.startswith("_")]) (numero pequeño) PyCon Argentina - Junin, Bs. As. 24/09/2011
  11. 11. Consejo: API (PROPIAMENTE HABLANDO) 2 • No exponer jerarquías profundas: No es lo mismo diseñar para la API que para reusar código. PyCon Argentina - Junin, Bs. As. 24/09/2011
  12. 12. Consejo: Cooperación con otras APIs • Compatibilidad con las pilas. • Seguir la PEP 8. • Ojo con retornar objetos de otras APIs (disminuye el clueless). • Ojo con redefinir comportamiento de otras APIs (aumenta el acoplamiento). PyCon Argentina - Junin, Bs. As. 24/09/2011
  13. 13. Consejo: Mis tipos, tus tipos • De preferencia NO exponer objetos propios como resultados de operaciones. • Librerías mías: • csvcool: Manipula csv y la función read devuelve una instancia de CSVCool • django-hatconf: Configuraciones distribuidas que usa settings.py de Django como schema. • pycante: La hice con la intención de "heredar" de los archivos .ui de QtDesigner. • Aplica también a mundo web: • XML: NO • JSON/YAML: SI PyCon Argentina - Junin, Bs. As. 24/09/2011
  14. 14. Consejo: Tipos • Los controles de tipos deben hacerse en el nivel de APIS • Los Controles de tipos llevan tiempo. • Los assert son buenas ideas para validar tipos. • Ojo con el retorno de valores nulos (None != default). def foo(arg): assert isinstance(arg, Something), "Bad Type expected {0}".format(Something.__name__) do something PyCon Argentina - Junin, Bs. As. 24/09/2011
  15. 15. Consejo: Errores • Llamamos errores a algo inmanejable por nuestra librería. • Los errores se solucionan lo mas tempranamente posible. • Errors should never pass silently, Unless explicitly silenced. • Crear excepciones propias puede ser un arma de doble filo. • Aumenta la capacidad de manejar errores desde la aplicación cliente • Disminuye la homogeneidad con las pilas PyCon Argentina - Junin, Bs. As. 24/09/2011
  16. 16. Consejo: Inmutabilidad Rulz! • Si van a definir objetos intentar que sean inmutables (aumenta bastante laestabilidad de la librería... bueno no realmente) • Darle muchos derechos al constructor (inmutabilidad) • Si un objeto es inmutable: -TRATAR de redefinir __repr__, __str__, __hash__, __cmp__, __eq__ y __ne__. • Si un objeto es mutable: • controlar mucho lo que llega por las API. • Redefinir: __repr__, __str__, __cmp__, __eq__ y __ne__. PyCon Argentina - Junin, Bs. As. 24/09/2011
  17. 17. Consejo: Diseño • Siempre planeen primero la funcionalidad. • TDD. • Primero el controller (MVC). • Plantear inicialmente el nivel de exelencia que se quiere llegar. PyCon Argentina - Junin, Bs. As. 24/09/2011
  18. 18. Consejo: PortandoLo importante es • Facilitar a la vida a los desarrolladores python: • Respetar pep8: assertTrue -> assert_true/ asserttrue • Utilizar funciones de python: obj.length() -> len(obj) • Utilizar metodos de python: obj.appendChild(aobj) -> obj.append(aobj) • Que vengan del lenguaje de la librería original. • Python no es Java PyCon Argentina - Junin, Bs. As. 24/09/2011
  19. 19. Consejos: Publicación • No publiquen sin tests. • TDD se merece una oportunidad. • Publiquen de manera comunes a los developers python (pypi > ppa). • No publiquen sin documentación. (mercurial -> git) • Vean la pagina de los chicos de Pocoo (http://www.pocoo.org/) • Dar identidad gráfica al proyecto. PyCon Argentina - Junin, Bs. As. 24/09/2011
  20. 20. Consejos: Finales • Hacer que nuestras cosas internas cumplan muchas de las cosas que dijimos. • Las APIs simétricas son buena idea (load, dump). • Tratar de cumplir en su totalidad el zen de python. • Compatibilidad patras • No abusar de los patrones. • Todo es cuestión de diseño (DRY or not DRY) • Evitar el monkeypatch. PyCon Argentina - Junin, Bs. As. 24/09/2011
  21. 21. ¿Preguntas? • Charlas: • http://bitbucket.org/leliel12/talks • Contacto: • Juan B Cabral • Mail: jbc.develop@gmail.com • Twitter: @JuanBCabral • Blog: http://jbcabral.wordpress.com/ PyCon Argentina - Junin, Bs. As. 24/09/2011

×