LibFree or Die Hard
Upcoming SlideShare
Loading in...5
×
 

LibFree or Die Hard

on

  • 1,331 views

 

Statistics

Views

Total Views
1,331
Views on SlideShare
780
Embed Views
551

Actions

Likes
0
Downloads
3
Comments
0

2 Embeds 551

http://jbcabral.com 311
http://jbcabral.wordpress.com 240

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

LibFree or Die Hard LibFree or Die Hard Presentation Transcript

  • 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.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
  • 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
  • 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
  • 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
  • No CluelessNadie sabe todo lo necesario para volar un avión. PyCon Argentina - Junin, Bs. As. 24/09/2011
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • ¿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