Etiqueta: python

Circular Dependencies Webcast por Miguel Grinberg

Un Webcast de Miguel Grinberg sobre como evitar Dependencias Circulares en una aplicación Python / Flask.

My Metadata

  • Descripción: Un webcast de 1h en el que se refactoriza una aplicación Flask que empieza con un único fichero a varios paquetes y módulos.
  • Calificación: 3 sobre 5
  • Día de Visualización: 2020-06-28
  • Año de publicación: 2018
  • Duración: 68 minutos
  • Velocidad de reproducción recomendada: 1.75
  • Etiquetas: python; flask; dependencies; refactoring

Lecciones aprendidas

  • Mantener el entry point tan limpio como sea posible. Incluso con un único import.
  • El módulo que es ejecutado inicialmente por Python adquiere el nombre de __main__ a nivel interno, por ello los «nombres» que se definan en este módulo, no se identificarán inicialmente a efectos de dependencias como myfile.myvar si no como __main__.myvar, lo que es más fácil que genere un error de dependencias circulares
  • No usar los __init__.py como mecanismo para acortar los imports. Hay tantas opiniones a favor como en contra sobre el tema. A mi me ha generado más problemas que soluciones.
  • Usar imports desde la «raíz» from myapp.models.user import User y no estilo from user import User.
  • No pasa nada por no poner los import al inicio del fichero cuando tenga sentido que sea de otra forma, por ejemplo para evitar dependencias circulares. Usar # noqa para que no pite el linter en estos casos es aceptable.

Libro: Dive Into Python

Hay una versión del libro para python 2, cuya última edición es de 2004, y una versión centrada en python 3 con algo de contenido reescrito. El autor original Mark Pilgrim hace tiempo que desapareció de internet, pero los libros continúan siendo mantenidos aunque poco actualizados en github.

Ambas versiones de los libros tienen buenas puntuaciones en Amazon y Goodreads [v2] [v3]

Se venden como un hands-on en python, es decir poca teoría y presentar ejemplos prácticos.

La estructura de ambas versiones es la misma para todos los capítulos comienza con un ejemplo de código, y a continuación lo explica paso a paso. Durante el proceso va introduciendo nuevas funcionalidades del lenguaje. Tal y como está estructurado no es adecuado para alguien sin conocimientos de programación previos. Tampoco me parece adecuado para gente que sepa de otro lenguaje y quiera aprender python.

Algunos de los capítulos de la segunda versión se quedan antiguos y/o muy específicos como trabajar con http, xml o html. La parte de testing, tdd y refactoring es bastante limitada y no me acaba de convencer, aunque hay que reconocer que pocos libros no específicos tratan estos temas, por lo que es de agradecer que al menos los mencionen. Los primeros tres capítulos y el de expresiones regulares son casi un relleno, me parecen avanzados para alguien que no sepa python, poco útiles para quien ya controle del lenguaje. Los capítulos de Introspección, POO, Programación Funcional y Funciones dinámicas pueden aportar algún conocimiento de interés y funcionalidades del lenguaje algo menos habituales de usar.

En la versión 3 pasa más o menos lo mismo, aunque los capítulos sobre Closures & Generatos, Classes & Iteratos, Advanced Iteratos, y Special Method Names son interesantes. Esta versión tiene un poco menos de carga en la parte de Programación orientada a objetos, así que esos capítulos se pueden revisar en la versión para python 2. Los capítulos sobre migración de python 2 a python 3 sólo son de interés para quien tenga que abordar un proyecto de ese tipo.

Si estás buscando un libro para aprender python sepas o no programar previamente esta no es una buena opción. Pero si merece la pena cuando ya tengas idea del lenguaje y estés buscando aprender un poco más y conocer algunos idioms, sobre todo en modo lectura rápida. Abre cada capítulo y trata de entender el ejemplo propuesto, si no tienes dudas puedes pasar al siguiente capítulo. Si el ejemplo tiene algo que te resulta de interés lee un poco más de ese capítulo.

Libro: Think Python: How to Think Like a Computer Scientist

How to Think Like a Computer Scientist es un libro clásico entre los recomendados para comenzar a programar en python. La primera edición es de 2002, escrito por Jeffrey Elkner, Allen B. Downey y Chris Meyers bajo licencia GNU FDL. El ser tan «antiguo» y el estar publicado bajo licencia libre ha hecho que a lo largo del tiempo hayan aparecido diversas versiones del libro.

Tenemos dos versiones del libro para python 2

  • How to Think Like a Computer Scientist: Learning with Python 2nd edition, sería la última edición para python 2 del libro original, y está fechada en 2012. Las soluciones a algunos ejercicios se pueden encontrar en wikibooks (y seguramente valgan para otras versiones).
  • La primera edición (2002) de ese mismo libro la podemos encontrar en Green Tea Press la página personal (y «editorial») de Allen B. Downey uno de los autores originales
  • Y también en Green Tea Press podemos encontrar una reedición distinta del mismo libro para python, renombrada simplemente a Think Python. Revisando el github donde se mantiene el libro los últimos cambios serios parecen ser de 2015

También tenemos varias versiones del libro enfocadas a python 3.

  1. La que podríamos considerar primera, de 2012, es How to Think Like a Computer Scientist: Learning with Python 3, reeditada fundamentalmente por Peter Wentworth como libro de texto para un primer curso de programación.
  2. Otra versión sería una adaptación de la de Peter Wentworth, hecha por varios profesores de la Universidad de Groningen, para emplearla también como libro de texto para sus clases. En el prólogo declaran que su idea era cambiar la filosofía del libro, de «how to think like a computer scientist» to «how to think as a scientist with a computer», pero revisándolo en mi opinión, los cambios no son tan significativos como para conseguirlo. Está en readthedocs por lo que también se puede descargar
  3. En Green Tea Press también encontramos una versión (los últimos cambios serios en el github son de 2016). Esta sería algo así como la segunda edición de Think Python
  4. Por último, un experimento interesante. Un libro interactivo, que parece basado fundamentalmente la versión de Wentworth. Consiste en una aplicación web que permite ejecutar código en el propio navegador, depurar paso a paso a modo educativo y responder a cuestionarios

En la página de Green Tea Press hay un dos artículos explicando porqué publicar «free books», y su filosofía a la hora de escribir libros de texto. Además en el prólogo del libro se puede leer algo sobre su historia para entender los autores y los cambios a lo largo del tiempo.

Todas las versiones (inluída la interactiva) están en repositorios de código en github o launchpad, por lo que es posible colaborar en su mejora. Y están escritos en reStructuredText o Markdown y convertidos a libros con sphinx u otras herramientas.

No resulta sencillo decir «cual es mejor», cada una de las veriones tiene sus puntos fuertes y débiles:

  • Los que hemos hemos numerado como dos y como tres son los que tienen para mi un orden de capítulos más lógico. Por ejemplo trata listas, tuplas y diccionarios en capítulos contiguos mientras que en las otras versiones los diccionarios están separados del resto de tipos de datos. Pero en dos han juntado varios capítulos en uno sólo por lo que su lectura se hace algo más difícil. Además los capítulos sobre numpy, matplotlib y data handling no encajan muy bien como están escritos en un libro para principiantes. Por tanto a pesar de ser el más actualizado yo en principio descartaría esta versión.
  • El uno tiene algún material adicional respecto a los otros como capítulos sobre estructuras de datos más avanzadas (pilas, colas y árboles). Si bien creo que estos capítulos son de interés, tampoco pasa nada por prescindir de ellos en un primer contacto, porque hay otros libros más avanzados o más específicos que tratan mejor este tipo de temas.

  • El número tres (Think Python) tiene para mi otros alicientes como que algunos de los problemas y soluciones están resueltos en el github del autor. Es de los que siguen un orden más lógico, capítulos cortos, y una sección «debugging» al final de cada capítulo que explica «técnicas mentales» a la hora de depurar y construír un programa que resultan útiles. Además se puede comprar a través de Amazon, descargar gratuitamente en PDF, leer en html… Así que seguramente esta es la versión más recomendable.
  • La versión interactiva también me ha sorprendido gratamente. El texto no es tan bueno como el de Think Python, pero el poder jugar con el código mientras leemos el texto, da muchas opciones a alguien que se introduce en el lenguaje y le permite aprender sin tener que liarse con el entorno. Además la opción de debug (codelens en su terminología es especialmente útil para ver lo que pasa en el programa). Esta tambień es un opción recomendable.

Entre la opción interactiva y Think Python es difícil decidirse, si quieres avanzar rápido y tener una panorámica general, el libro seguramente es mejor, y la irrupción de cajas y botones en medio del texto menos molesta. Depende del estilo de aprendizaje de cada uno. Leer un par de capítulos de cada uno y decide tu mismo.

Si está revisión te ha ahorrado tiempo y quieres agradacerme el esfuerzo planteate donar usando el botón de la derecha, o simplemente dejar un comentario en esta entrada.

Libro: A Byte of Python de Swaroop C H

El libro «A Byte of Python» es uno de los que se suelen recomendar en las QA de como iniciarse en el desarrollo con Python. Es un libro corto, unas 120 hojas en la versión impresa que se puede ojear en apenas un par de horas. Está distribuído bajo licencia CC-by-sa 4.0 y el desarrollo se realiza en github. Al ser libre hay distintas versiones en la red, la canónica está en la página del autor y es la que se debería leer.

El libro hace un repaso básico a la sintaxis del lenguaje, sin entrar en demasiada profundidad en ningún tema y con ejemplos tipo «¡Hola mundo!». Tampoco se para demasiado en conceptos de teoría de la programación, como explicar que es una variable o un lenguaje interpretado pero si lo menciona. Eso sí, la terminología que emplea para hacer referencia a los conceptos es correcta.

Creo que es una buena guía si ya sabes algo de programación en otro lenguaje y quieres de una forma rápido poder empezar a hacer cosas con python, pero no es adecuado como primer contacto con el mundo del desarrollo.

Atom: Autocompletado de código en python

Al margen del «Code Completion» de PyCharm, y algún otro, el resto de editores/IDEs proveen autocompletado a través de librerías o «servicios externos». Para el caso de python hay fundamentalmente dos, rope y jedi. Rope está más enfocada a Refactoring y Jedi a Autocompletado, por tanto las dos son complementarias. En la actualidad varios editores que usaban rope están migrando a jedi, su autor ha hecho una comparación defendiendo su librería.

Además de estas librerías cada editor suele proporcionar un plugin base para autocompletado (autocomplete-plus en atom, auto-complete en emacs) y plugins adicionales para cada lenguaje concreto que actúan como wrapper de las librerías base (rope, jedi,…). Por ejemplo en atom tenemos autocomplete-python que es un wrapper para jedi.

Instalación

Primero hay que instalar jedi sea a nivel global como en el ejemplo, o dentro de un virtualenv.


sudo pip install jedi

Luego se instala el plugin de autocomplete-pyhon (que es el más actualizado de los varios que hay). Si usas virtualenv también debería funcionar sin problemas pero si usas algo como virtualenvwrapper donde tu módulo está en un directorio distinto al «entorno virtual de python» puedes haber más problemas.

Lanzado atom desde un virtualenv activado siempre funciona correctamente. Si lo lanzas de otra forma hay que configurar la opción de configuración Python executable path del plugin con algo como:


PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT_NAME/bin/python

o

PATH_TO_VIRTUALENV_WRAPPERS_FOLDER/$PROJECT/bin/python

Donde PATH_TO_VIRTUALENV_WRAPPERS_FOLDER es la ruta absoluta al directorio donde se guardan todos los entornos virtuales de virtualenwrapper y $PROJECT_NAME y $PROJECT son cadenas que debes escribir tal cual. Son variables que entiende el plugin. De la documentación parece deducirse que lo que hay que usar es $PROJECT pero a mi me ha funcionado sólo con $PROJECT_NAME. Además el directorio padre que se añade a atom a través del «Add project folder» debería llamarse igual que el virtualenv para que $PROJECT_NAME tome el valor correcto y puedas usar la misma configuración para distintos proyectos.

Uso

Por la naturaleza dinámica de python muchas veces jedi no es capaz de detectar el tipo de datos de un objeto. Pero podemos ayudarlo documentado el método. Por ejemplo en un caso como el del ejemplo siguiente con una vista de pyramid, jedi no será capaz de determinar el tipo de datos del parámetro request.


@view_config(route_name='my_route')
def my_route(request):
pass

Pero si hacemos lo siguiente si que autocompletará correctamente los métodos de request:


def cultivos_get(request):
"""
:type request: pyramid.request.Request
"""
pass

No lo he probado con python 3 para ver si soporta el type hinting pero este issue me hace suponer que si.
Teclas principales

  • Sugerencias de autocompletado. Ctrl+space Cursores y tab/intro para escoger y aceptar sugerencia
  • Go to definition: Ctrl+Alt+G
  • Show usages: Ctrl+Shift+P show usages
  • Renombrado en varios ficheros a la vez: Con el cursor encima del símbolo. Ctrl+Shift+P rename

Conclusiones

Las funcionalidades que proporciona son de todas formas muy justas porqué a no ser que documentes los métodos, la mayoría de veces no es capaz de inferir el tipo de datos de una variable. Además las funciones de autocompletado normal de atom incluyen habitualmente opciones que no tienen porque corresponder con métodos o propiedades reales del objeto. Y si se desactiva el autocompletado normal para los ficheros python, tendremos muy pocas sugerencias.

Video: Aplicaciones en tiempo real con python y postgres

Una charla de como montar aplicaciones en tiempo real con python y postgres. Tiempo real entendido como notificaciones de un chat, hacer algo cada vez que se actulice una tabla de la bd etc,…

El vídeo se hace un poco largo, seguramente con las transparencias llegaba para hacerse una idea general. Pero aún así se hace interesante por alguna de las técnicas que emplea:

  • Aboga por no usar frameworks en python. Con las librerías de hoy en día es sencillo montar una API Rest gestionando las llamadas de bajo nivel directamente
  • Usa las funciones de postgres de LISTEN y NOTIFY que combinadas con un trigger permiten que código cliente (psycopg2) sean notificados cuando algo pasa en la base de datos (se modifica una fila o lo que sea) y actuén en consecuencia (provocar un cambio en el navegador mediante websockets)
  • Para simplificar la API y el diseño de la bd, los datos se guardan como tipos nativos postgres (varchar, boolean,…), y se usa la función de postgres row_to_json para recuperarlos una cadena de texto con formato json.
  • Usa httpie para probar la API Rest. Si alguna vez usaste curl para esto enseguida verás que está bien conocer httpie.
  • A pesar de que la idea principal de la charla es montar una aplicación en tiempo real con el mínimo número de dependencias (complejidad) el proceso de build que monta no parece trivial. pip para dependencias en python, nodeenv (una especie de entorno virtual para node que se integra con el virtualenv de python), bower para las dependencias javascript de cliente,… Todo ello orquestrado por un Makefile.
  • No muestra como hacer la parte del frontend, pero en todo caso el código está en su repo

Emacs y análisis estático de código en python

Gracias a Cartolab he podido seguir dándole una vuelta al análisis de código estático en python. La idea era reducir los incómodos errores que se producen porque te equivocas al escribir el nombre de una variable o cosas parecidas de las que no te das cuenta has que ejecutas el código. Tratar de detectar estos errores de la forma en que lo veíamos en el artículo anterior sigue sin ser demasiado productivo y aquí es donde entra en juego la extensión para emacs Flymake.

Lo que hace Flymake es «pedirle» a emacs que esté continuamente realizando ciertos análisis sobre el código o tratando de compilarlo y/o ejecutarlo. En realidad flymake es un plugin bastante genérico que funciona del siguiente modo:

  1. Si al abrir un nuevo buffer está marcado como «a chequear», flymake programa un temporizador para el buffer. La forma de marcar buffers suele ser en función de la extensión del archivo que abramos
  2. Crea una copia temporal de los buffers abiertos cada cierto tiempo
  3. Ejecuta un programa externo sobre la copia del buffer. Este programa puede ser gcc, make u otra cosa como una herramienta de análisis estático de código.
  4. Parsea la salida que produce el programa externo y da una salida visual en el buffer actual para representar los posibles errores.

Activar flymake

Activar flymake junto a alguna de las herramientas que veíamos en el post anterior es bastante fácil. Flymake viene instalado por defecto, así que sólo tenemos que tener en el path los ejecutables a las herramientas de análisis, y añadir a nuestro .emacs las instrucciones para que se activen con los ficheros python.

flymake con pyflakes:

(when (load "flymake" t)
(defun flymake-pyflakes-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "pyflakes" (list local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pyflakes-init)))

flymake con pylint (el comando epylint es un modo especial de pylint para trabajar con emacs)

(when (load "flymake" t)
(defun flymake-pylint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "epylint" (list local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))

flymake con pep8
(when (load "flymake" t)
(defun flymake-pylint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "pep8.py" (list "--repeat" local-file))))
(add-to-list 'flymake-allowed-file-name-masks'("\\.py\\'" flymake-pylint-init)))

Por otro lado también podriamos configurar flymake para hacer que se pasarán las tres herramientas de forma automática pero yo lo veo innecesario dado que la información que proporcionan es en muchos casos redudante y estamos disminuyendo el rendimiento del ordenador.

Además de indicarle a flymake con que herramienta queremos trabajar, tenemos que activarlo para los buffers que nos interesen. Esto podemos hacerlo de varios modos:

  • Manual. Activando el modo menor de flymake. M-x flymake-mode
  • Que active el modo menor flymake cuando estemos en el modo python. Añadiendo al .emacs
    (add-hook 'python-mode-hook 'flymake-mode)
  • O que active el modo flymake en base a las extensiones de fichero que le hemos pasado anteriorme (flymake-allowed-file-name-masks)
    (add-hook 'find-file-hook 'flymake-find-file-hook)

Configurar flymake

Por defecto flymake ilumina (highlight) la línea de código donde se produce el error, empleando un color u otro en función de si es un error o un warning. Al dejar el ratón encima de la línea con el error (hover) nos muestra la descripción del error.

Para cambiar los colores que se emplean por defecto podemos emplear algo parecido a esto:

'(flymake-errline ((((class color)) (:background "LightPink" :foreground "black"))))
'(flymake-warnline ((((class color)) (:background "LightBlue2" :foreground "black"))))

Para que subraye en lugar de hacer highlight de la línea con el error:

'(flymake-errline ((((class color)) (:underline "red"))))
'(flymake-warnline ((((class color)) (:underline "yellow")))))

Para hacer que el fringe derecho se muestre un indicador de en que líneas hay errores podemos usar rfringe. Aunque yo no he sido capaz de hacerlo funcionar.

Mostrar la descripción del error en el minibuffer. Esto es imprescindible cuando se trabaja en modo -nw.

(defun my-flymake-show-help ()
(when (get-char-property (point) 'flymake-overlay)
(let ((help (get-char-property (point) 'help-echo)))
(if help (message "%s" help)))))
(add-hook 'post-command-hook 'my-flymake-show-help)

Aunque el código anterior a mi me funciona, para mostrar el error en el minibuffer se suele emplear el plugin flymake-cursor.

Moverse a través de los errores. Podemos emplear los comandos M-x flymake-goto-prev-error para ir al error anterior, o M-x flymake-goto-next-error para ir al siguiente. También podemos vincularlos a determinadas teclas:

(global-set-key [TECLA] 'flymake-goto-prev-error)
(global-set-key [TECLA] 'flymake-goto-next-error)

Links relacionados

Herramientas de análisis de código estático en Python

Programar es fácil, y puede hacerse con el bloc de notas. Escribir buen código es bastante más complicado, por ello existen un montón de herramientas que pueden ayudarnos. Un tipo de herramientas que he empezado a usar (en python) ultimamente son las de análisis estático de código. Estas herramientas examinan tu código (sin ejecutarlo) en busca de ciertos patrones, alertando de «code smells», incroguencias de estilo, posibles bugs, código repetido e incluso dando consejos sobre rendimiento o encapsulamiento en algunos casos.

En python tenemos disponibles distintos analizadores de código, y es habitual ver preguntas sobre cual es mejor. Las cuatro herramientas de este tipo para python están actualizadas a las últimas versiones en los repositorios de ubuntu. Para instalarlas:

sudo apt-get install pyflakes pep8 pychecker pylint

Pyflakes

Pyflakes parece la más sencilla de las cuatro herramientas que he usado. Hace pocas comprobaciones del tipo, imports no usados, variables asignadas y no empleadas, …
No chequea el estilo, ni advierte sobre posibles bugs, aunque dicen que es de las más rápidas, por lo que es la que la gente suele usar como «chequeador de código automático» en IDEs como PyDev o emacs.

pep8

pep8 valida el estilo de nuestro código (de forma bastante rigurosa) contra el estándar de estilo PEP8 de Python. Puede ayudar a detectar «code smells», pero no chequea «errores». Comprueba cosas como que las líneas no tengan más de 80 caracteres, los nombres de variables tengan un determinado formato, …

Para chequear un fichero llega con hacer:
pep8 nombre_de_ficheros.py

Aunque habitualmente se lanza con más opciones para obtener más información:
pep8 --show-source --show-pep8 nombre_de_ficheros.py

Cuando lo lanzamos con –show-pep8 proporciona bastante información sobre la regla de estilo que estamos rompiendo por lo que resulta útil para ir interiorizándolas.

Pychecker

Pychecker es la más antigua pero ahora está algo parado. La última versión 0.8.19 es de enero de 2011 y la anterior del 2008. PyChecker si que es bastante potente en cuanto a la detección de posibles bugs o errores como el de usar una variable antes de asignales un valor, llamar a un método que no existe, … En general detecta bastantes de esos errores que se cometen en python (cuando no se usa un IDE que ya detecte estas cosas)
Parámetros interesantes.
–blacklist=unittest Este módulo de python saca algún error con pychecker, así que para evitar ruido le decimos que no lo chequee.

Pychecker tiene, imho, un problema gordo, y es que ejecuta el código para chequearlo, no es realmente una herramienta de análisis estático, por lo que su uso es más bien desaconsejable.

Pylint

Pylint es una especie de mezcla entre pep8 y pychecker puesto que hace análisis tanto del estilo del código como de posibles bugs. Tiene un montón de características, es extensible mediante plugins, …

El informe que proporciona sobre el código es bastante extenso, clasifica los errores por su gravedad, … Como tiene muchas opciones es conveniente echarle un ojo al tutorial y al manual aunque no hace falta para ver su potencial.

Los parámetros más interesantes de pyling son:

  • –reports=n Para que sólo nos saque los posibles errores y no imprima las estadísticas e informes. Puede ser útil ver el informe de vez en cuando, pero si vamos a pasar el chequeo muchas veces sólo mete ruido.
  • –include-ids=y Por defecto no nos muestra el código de error completo. Con esto hacemos que nos lo muestre para poder obtener más información sobre él si no lo entendemos (Esto lo haríamos con pyling –help-msg=ERROR_CODE)
  • –disable=C0111 Esto hace que no se chequeen, los errores C0111, que indican que todos los métodos deberían tener un docstring. Me gusta eliminarlos porque soy de los que piensan que «los comentarios apestan»

Para que la línea de comandos no se vuelva muy complicada estás opciones pueden indicarse en un fichero de configuración para que sean usadas por defecto

Como y cuando usarlas

Lo que me gusta de estas cuatro herramientas es que no hay excusa para no usarlas. Son realmente sencillas, rápidas, y ayudan a hacer un código más legible y mantenible.

Por ahora, para acostumbrarme a ellas, lo que hago es al inicio de cada sesión de trabajo paso las cuatro herramientas en el siguiente orden:

  1. pep8 –show-source –show-pep8 *.py
  2. pylint –reports=n –include-ids=y –disable=C0111 *.py
  3. pychecker –blacklist=unittest *.py
  4. pyflakes *.py

Lo hago así porque me gusta la información sobre el estilo que proporciona pep8, y tras solucionar los errores de pylint ni pychecker ni pyflakes me están proporcionando ayuda adicional así que es probable que pronto deje de usarlos. De hecho cuando me acostumbre a la guía de estilo de pep8 es probable que sólo use pylint.

Como el proyecto en el que la estoy probando apenas son 6 o 7 clases de alrededor de 200 líneas, está forma de trabajar me resulta cómoda y me permite aprender a usarlas, pero está claro que en otros contextos puede no ser lo más adecuado.

En el próximo artículo de esta serie hablaremos sobre como integrar estas herramientas en emacs, al estilo de las sugerencias de eclipse u otros IDE, y otras aproximaciones un poco más sofisticadas de como integrarlas en nuestro flujo de trabajo.

¡Prueba y cuéntame!

Actualización 20/Julio: He añadido algún enlace y desaconsejado el uso de pychecker por las razones que ya están incluídas en el propio artículo.

Python Scripting for Students of Remote Sensing

Python Scripting for Students of Remote Sensing es un manual de python orientado a la teledetección. Si no sabes nada de python es mejor empezar por otro manual y luego saltar directamente al capítulo 5, «Plottin». La parte de python en sí es muy básica y no está muy bien explicada. Del capítulo 5 al 10 se muestran algunas librerías interesantes de python para mostrar gráficos (matplotlib), para estadística y calculos científicos (numpy), para procesado de raster (gdal), o ejemplos sencillos de trabajo con datos lidar en ficheros ascii. La información que dan es bastante escueta, pero si ya conoces python en un par de horas puedes leerlo para hacerte una idea de que posibilidades hay en estos campos.

En la misma página se pueden encontrar otros manuales interesantes sobre teledetección.

Descubrí el curso gracias al comentario de José Guerrero.

 

 

 

Um curso objetivo de programação em Python

Gracias al blog de Anderson Medeiros encuentro un interesante tutorial de python escrito en Portugués pero muy facilito de seguir.

Es un tutorial de introducción, rápido de leer y que me ha ayudado a recordar algunos de esos conceptos que por estar más habituado a otros lenguajes tipo Java no empleas a menudo.

Algunas cosillas que he recordado, aprendido o me han gustado.

Listas, tupas y strings

Explica bien que son listas, tuplas, diccionarios y strings. A listas y tuplas se las llama en ocasiones secuencias puesto que sus propiedades son muy parecidas. Una tupla es en realidad una lista inmutable.

Conviene tener en la cabeza lo fácil que es hacer slices (subconjuntos de secuencias) y substrings en python, incluso empleando índices negativos para empezar a contar por el final. LLega con escribir:

>>> lista = ['a', 'b', 'c', 'd', 'e', 'f', 'g']
>>> lista[2:5]
['c', 'd', 'e']
>>> lista[2:]
['c', 'd', 'e', 'f', 'g']
>>> lista[:5]
['a', 'b', 'c', 'd', 'e']
>>> lista[:-2]
['a', 'b', 'c', 'd', 'e']
>>> lista[-2:]
['f', 'g']

Los operadores * y + se pueden usar sobre listas, tuplas y strings. * replica n veces el elemento y + concatena.

Ejemplo para strings:

>>> a = "exato"
>>> print a * 2
exatoexato
>>> print "quase " + a
quase exato

Ejemplo para listas:

>>> a = [-1, 0]
>>> b = [1, 2, 3]
>>> print b * 3
[1, 2, 3, 1, 2, 3, 1, 2, 3]
>>> print a + b
[-1, 0, 1, 2, 3]

Para chequear si un elemento está contenido en una secuencia o diccionario se usa el operador in

>>> "x" in "cha"
False
>>> 1 in [1,2,3]
True

Combinar de forma implícita operaciones lógicas

Además de los operadores lógicos not, or, and python permite combinar ciertas operaciones lógicas de forma implícita:

Por ejemplo podemos comprobar un número está en un determinado rango de esta forma:

a = 5
if 3 < a < 9:
print "Entre 3 y 9"

a = 3; b = 3; c = 2;
if a == b <= c:
print "a igual a b y b menor o igual que c"

Clausula else en bloques for y while

En los for y los while se puede emplear una claúsula else que se ejecutará cuando se salga del bloque de iteración por haber acabado la secuencia (en lugar de salir por un break)

valores = [2, 4, 5, 2, -1]
for i in valores:
if i < 0:
print "Negativo encontrado: %d" %i
break
else:
print "Nenhum negativo encontrado"

Valores booleanos

No está de más recordar que en python se considera falso a:

  • el booleano False
  • el valor 0 (zero)
  • una lista, diccionario, tupla o string vacios (de tamaño cero)
  • el valor especial None

Así por ejemplo para comprobar si una lista no está vacía mejor que emplear

lista = ['a']
if (len(lista)) != 0:
print "forma poco apropiada de comprobar si una lista no está vacia"

usaremos directamente

if lista:
print "Lista no vacia"

Argumentos de funciones

Existen dos formas de pasar un número variable de argumentos a una función:

def desculpa(alvo, *motivos):
d = "Desculpas %s, mas estou doente" % alvo
for motivo in motivos:
d = d + " e %s" % motivo
return d + "."

>>> desculpa("senhor", "meu gato fugiu",
... "minha tia veio visitar")

o bien

def equipe(diretor, produtor, **atores):
for personagem in atores.keys():
print "%s: %s" % (personagem, atores[personagem])
print "-" * 20
print "Diretor: %s" % diretor
print "Produtor: %s" % produtor

>>> equipe(diretor="Paul Anderson",
... produtor="Paul Anderson",
... Frank="Tom Cruise", Edmund="Pat Healy",
... Linda="Julianne Moore")

Frank: Tom Cruise
Edmund: Pat Healy
Linda: Julianne Moore
--------------------
Diretor: Paul Anderson
Produtor: Paul Anderson

Si tienes algún tutoirial de python que te haya gustado o algún truquillo que quieres compartir deja un comentario.