Joaquin Sorianello: Zafá del xml con Tryton Builder!

Hay cosas que no me gustan, y hay cosas que detesto. En esa escala de valores, en el primer lugar está PHP y en el segundo los XMLs. Como conté en el post anterior, estoy desarrollando algunos módulos para Tryton, que define sus vistas, y elementos de interacción usando ese lenguaje de markup.

Hay varios artículos que hablan que uno tiene que ser un programador vago, yo estoy totalmente de acuerdo con que hay que ser un programador que automatiza al máximo el trabajo que no le gusta hacer, para poder dedicar el tiempo a problemas mas complicados o atractivos, o a mirar por la ventana.

En mi intento por zafar de escribir varios cientos de  '<',' /', y '>' a mano nació Tryton Builder (Que tiene logo y todo!)


Por el momento, para generar un módulo, hay que escribir un pequeño archivo de código (Si, es código python, porque me gusta programar, no parametrizar, yamls, csv, y ese tipo de cosas) de este estilo:



En el ejemplo, estoy realizando todos los pasos para generar el modulo de ejemplo del wiki de tryton

Solo para comparar la diferencia de caracteres escritos versus generados:

El proximo paso, es armar una interfaz de consola como la de los scaffolders de Ruby On Rails




Joaquin Sorianello: Monkey Patcheando Element tree para soportar cdata

Hace un tiempo que estoy trabajando con Tryton, el ERP libre, escrito en python, y como me gustan los scaffolders de Rails, decidí escribir uno para armar los esqueletos de los módulos. Tryton, no se bien por que motivo, utiliza mucho xml, para definir vistas, y fixtures de datos. Como me gusta programar en python, me empezé a escribir una especie de DSL para definirlos de una manera mas amigable:
https://github.com/joac/tryton_builder

Python permite trabajar con xml con un montón de bibliotecas distintas, pero las mas amigable de usar, para mi es ElementTree

Cuando empece a escribir el codigo, y hacer pruebas, me encontré con varios problemas, el primero, ElementTree no tiene "Pritty Print"
para que el xml generado sea mas cómodo de leer, por suerte encontré esta receta:


en http://effbot.org/zone/element-lib.htm#prettyprint que resolvió correctamente el problema

Avanzando en el diseño de los scaffolders me encontré con otra limitación  ElementTree no soporta el tag CDATA. Usted podria preguntarse "¿Que es el tag CDATA?", Básicamente un tag que le dice al parser "Lo que esta aca adentro es un conjunto de caracteres, no lo parsees"
Si bien se puede evitar el uso del tag, ingresando el texto escapado (por ejemplo, en lugar de '>' escribir '&gt' ) el objetivo es que el XML no deje de ser legible, encontré otras recetas en StackOverflow:
http://stackoverflow.com/questions/174890/how-to-output-cdata-using-elementtree

Pero finalmente, decidí escribir mi propia versión basada en algunos de los comentarios (la receta con mas votos no funciona en python 2.7+)

alecu: Muy enojado con Dell

(You can also read this article in english)

Compré un monitor Dell. Tachen eso: En verdad, tan sólo me cobraron un monitor Dell hace 45 días, y todavía no lo recibí, y ya estoy cansado de reclamarle a Dell.

Me pasé horas al teléfono, mandé mails que no me respondieron, intenté usar su rotísimo sistema de chat, su laberíntico web site, y nada.

image

A continuación, la historia completa:

Vengo escuchando acerca de lo buenísimo que es trabajar con doble pantalla, asi que me tenté y el 11 de Abril entré en dell.com.ar, elegí un bonito monitor de su línea profesional (U2713HM), lo pagué y me puse a esperar contento.

Ese mismo día recibí el primer mail, con la “notificación” de mi orden. Era un mail de texto plano, pero todo los datos estaban bien.

Tres días más tarde, el 15 de Abril, recibí el segundo mail, con la “confirmación” de mi orden. Todo seguía bien.

El 23 de Abril recibí su tercer mail, titulado “Se ha enviado el pedido”. Me decía que la fecha estimada de entrega iba a ser entre el 6 y el 9 de Mayo. El mail se veía mejor que los otros dos emails, pero… LA DIRECCIÓN DE ENVÍO ESTABA MAL!

La dirección estaba perfecta en los dos mails anteriores, pero en el tercero, el que decía “se ha enviado el pedido”, de alguna manera aparecía mi dirección de facturación en vez de mi dirección de envío. Para rematarla, en el mismo email aparecía el teléfono que puse como alternativo (el de mi señora) como teléfono principal de la orden.

Llamé a Dell el mismo día, estuve en el teléfono más de 45 minutos entre la espera y mientras hablaba con “Rosa”, que me pidió mi dirección de envío correcta, y que prometió llamarme tres días más tarde. También me dio un número de reclamo. Y explicitamente le expliqué que esto debería ser un bug en su sistema, dado que la dirección había estado correcta en los dos primeros mails.

Nunca me devolvieron el llamado, asi que tuve que llamarlos varias veces más. Cada tediosa llamada tuvo un promedio de 30 minutos. Llamé el 9 de Mayo y “Victoria” me informó que mi orden en realidad no había sido enviada todavía! El mail decía lo contrario, asi que Victoria me informó que Rosa me llamaría. Pero… nunca me llamaron.

Llamé el 14 de Mayo, y “Gabriela” me dijo que para poder autorizar el cambio tenía que mandar una copia de mi documento de identidad junto con (nuevamente!) la dirección correcta de envío. Tenían esa dirección desde mi compra original, estaba en los dos primeros mails que recibí de Dell, estaba todavía en mi cuenta del sitio de Dell como la única dirección de envío, y aún así, me la volvían a pedir.

Les mandé por mail la dirección correcta y la copia del documento ese mismo día, tal como me pidieron. Incluí “At. Rosa Jimenez”, como me pidieron. Pero de nuevo, ninguna respuesta.

Llamé el 17 de Mayo, para ver si la dirección había sido efectivamente cambiada, y me dijo “Saúl Concepción” que no había sido cambiada todavía, y que por favor intente manderle el mail a él. Y también me informó que el envío de hecho ya estaba en Argentina desde la semana anterior, pero esperando la verificación eléctrica que se le hace en Aduana a los dispositivos electrónicos importados al país. Y que esta espera tomaba unos “10 días hábiles”. Pero como ya había pasado una semana, me dijo que el monitor me llegaría en diez días más.

Volví a fijarme en el sitio web de dell.com.ar el 23 de Mayo, para ver si la dirección de envío había sido finalmente cambiada, pero la orden todavía tenía la dirección incorrecta. Como estaba cansado del teléfono, probé contactarlos vía chat.

El sitio web de Dell es un horrible laberinto, y al clickear en la opción de chat de “soporte a pedidos” te lleva a una página rota. Intenté con el chat de vendedores, y tras perder 15 minutos explicandole el problema a “LA_DHS_Emerson_Mendoza” logré que me transfirieran al chat de soporte de pedidos. Otra pérdida de tiempo, el chat.

"PAN_Luis_Ponce” fue la persona de soporte que me atendió, y me confirmó que la dirección había sido actualizada, (a pesar del que el sitio web muestra al día de hoy la dirección incorrecta). Y me informó que la verificación eléctrica había terminado, y que el monitor ya estaba en manos del courier, y que recibiría el envío en los siguientes tres días hábiles.

Eso significa que debería haber llegado hoy. Pero no llegó. Y ya perdí la paciencia.


Estoy muy enojado con Dell Argentina, y Dell Latin America.

PD: mirando el primer email nuevamente, veo esto en letra pequeña:

Si ocurre alguna demora, estaremos en contacto con usted.

El segundo mail fue un poco más explícito:

Aunque no anticipamos una demora con su pedido, ocasionalmente tenemos demoras no esperadas en el proceso de manufactura. Si ocurre alguna demora, estaremos en contacto con usted.

(el énfasis es mío, porque nunca se contactaron para decirme que habría alguna demora).

alecu: Very disappointed with Dell

(Este artículo está también en castellano)

I purchased a very nice Dell monitor. No, scratch that: I actually just paid for a Dell monitor 45 days ago, and have not received it yet, and I’m really tired of dealing with Dell.

I spent hours on the phone, I sent emails that were not answered, I tried to use their broken chat site, used their labyrinth of a web site, and nothing still.

image

Click to read the full story:

I’ve been listening great things about working with dual screens, so I got tempted and on April 11th I logged into dell.com.ar, chose a nice monitor from their professional line (U2713HM), purchased it, and happily started waiting.

The same day I got the first mail, with the “notification” for my order. It was a plain text email, but everything looked good.

Three days later, on April 15th I got the second mail, with the “confirmation” of my order, and with the order number. Everything looked good still.

On April 23th I got their third mail, the “your order has been sent” mail. It had an estimate delivery date (between May 6th and May 9th), it looked nicer than the two other emails, but… THE DELIVERY ADDRESS WAS WRONG!

It had been perfect in the previous two emails, but in the third email, the one that actually said “your shipment has been sent”, they have somehow managed to put my billing address in the place of my shipping address. To top it off, in that same email they managed to put the phone I put as the alternate (my wife’s) as the main phone of the order.

I called Dell support the same day, was on the phone more than 45 minutes between the wait and while talking with “Rosa”, who asked for my correct shipping details, and promised to call me back three days later, and got a support ticket number. I explicitly told them that there might be a bug in their system, since the address was right for the first two mails I got.

They never called me back, so I tried calling Dell support a few more times, each tedious call averaging 30 minutes. I called on May 9th and was informed by “Victoria” that my order had in fact not been shipped! Victoria told me that she would get Rosa to call me back. But I never got any call from them.

I called on May 14th and got told by “Gabriela” that I had to send them a copy of my national ID together with (again!) the correct shipping address. They had that address since my original purchase, it was present in the first two emails I received from them, it was still present in the website in my Dell account as the only shipping address, and yet, they requested it again.

I sent both the same day, as they requested it, with the name of Rosa Jimenez in the mail, as they requested. But again, got no answer.

I called on May 17th, to check if the address had been actually changed, and got told by “Saul Concepción” that the address had not been changed, and that I may try sending him that email. He was nice to wait on the phone and acknowledge the email reception. And he also told me that the shipment was in fact already in Argentina since the previous week, but waiting for the electrical safety check that is usually done to electronics entering this country. And that this wait usually took “10 working days”. So he told me that since one week had already passed, I should get my monitor by May 27th.

I checked the dell.com.ar website again on May 23th, to see if the shipping address had been finally changed, but the order still had the wrong address, so tired as I was of the phone, I tried contacting them via chat.

The dell.com.ar website is an awful maze, and clicking on the option to chat with “shipment support” still leads to a broken page. I tried then with the “sellpeople” chat, and after chatting for 15 minutes and explaining the problem to “LA_DHS_Emerson_Mendoza”, I got transferred to the “shipment support” chat. A waste of time, again.

“PAN_Luis_Ponce” was the support person, and he told me that the address was successfully changed (even though the website still showed the wrong one), and the the electrical safety check was done. Most importantly, he told me that I would be receiving the shipment in the following three working days. That means, that it should have arrived today. But it still hasn’t. And I’ve lost my patience.

I’m very disappointed with Dell Argentina, and Dell Latin America.

PS: Checking their first mail again, I now notice this in the small type:

If any delay happens, we’ll contact you.

The second mail was a bit more explicit:

“Even though we don’t anticipate any delays with your order, sometimes we have unexpected delays in the manufacture process. If any delay happens, we’ll contact you”.

(emphasis mine, because they never actually contacted me to tell me there was any delay).

Marcelo Fernández: Cómo compartir un dispositivo serie por la red en Linux

En el trabajo me encontré con la necesidad de utilizar un puerto serial (por ejemplo, un dispositivo con un adaptador USB/Serie en /dev/ttyUSB0, un módem 3G o una placa Arduino en /dev/ttyACM0, etc.) conectado físicamente a una máquina en mi red, que por diferentes motivos (distancia, pereza, lo que sea), lo quería acceder con un programa en mi máquina, pero como si fuera local.

Es decir, tenía un programa en mi máquina que usa pySerial para acceder al Arduino en /dev/ttyACM0, pero por diferentes motivos el Arduino está conectado en otra máquina de mi red y quería que, sin tocar mi programa, éste acceda al Arduino como si estuviera directamente conectado a mi PC, haciendo de alguna manera “transparente” la red que nos separaba. Por suerte lo pude resolver, y quizás esta herramienta y acercamiento sirva a más de uno para resolver algún otro problema similar.

Para esto vamos a utilizar la herramienta socat, que es como netcat pero para streams bidireccionales. Los pasos son:

  • Instalar socat (apt-get install socat), tanto en la máquina que tiene el dispositivo serie real (vamos a llamarlo “servidor”) como en el “cliente”.
  • Ejecutar en el servidor: “socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337”:
usuario@servidor:~$ socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337
2013/05/27 10:40:53 socat[2703] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 10:40:53 socat[2703] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 10:40:53 socat[2703] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 10:40:53 socat[2703] N opening character device "/dev/ttyACM0" for reading and writing
2013/05/27 10:40:53 socat[2703] I open("/dev/ttyACM0", 02, 0666) -> 3
2013/05/27 10:40:53 socat[2703] I socket(2, 1, 6) -> 4
2013/05/27 10:40:53 socat[2703] I starting accept loop
2013/05/27 10:40:53 socat[2703] N listening on AF=2 0.0.0.0:31337
2013/05/27 10:40:58 socat[2703] I accept(4, {2, AF=2 192.168.1.150:44624}, 16) -> 5
2013/05/27 10:40:58 socat[2703] N accepting connection from AF=2 192.168.1.150:44624 on AF=2 192.168.1.93:31337
2013/05/27 10:40:58 socat[2703] I permitting connection from AF=2 192.168.1.150:44624
2013/05/27 10:40:58 socat[2703] I close(4)
2013/05/27 10:40:58 socat[2703] I resolved and opened all sock addresses
2013/05/27 10:40:58 socat[2703] N starting data transfer loop with FDs [3,3] and [5,5]

Esto hace que socat abra el archivo /dev/ttyACM0 (el dispositivo serie a compartir), y además abra un socket en modo LISTEN (escuchando por conexiones) en todas las interfaces del equipo, particularmente en el puerto 31337. Las opciones -d -d -d son opcionales y sirve para habilitar los mensajes de debug.

  • Ejecutar en el cliente “socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/dev/ttyACM0”:
usuario@cliente:~$ socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/tmp/ttyACM0
2013/05/27 11:52:34 socat[8408] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 11:52:34 socat[8408] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 11:52:34 socat[8408] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 11:52:34 socat[8408] N opening connection to AF=2 192.168.1.93:31337
2013/05/27 11:52:34 socat[8408] I starting connect loop
2013/05/27 11:52:34 socat[8408] I socket(2, 1, 6) -> 3
2013/05/27 11:52:34 socat[8408] N successfully connected from local address AF=2 192.168.1.150:45293
2013/05/27 11:52:34 socat[8408] I setting option "symbolic-link" to "/tmp/ttyACM0"
2013/05/27 11:52:34 socat[8408] I openpty({4}, {5}, {"/dev/pts/4"},,) -> 0
2013/05/27 11:52:34 socat[8408] N PTY is /dev/pts/4
2013/05/27 11:52:34 socat[8408] I resolved and opened all sock addresses
2013/05/27 11:52:34 socat[8408] N starting data transfer loop with FDs [3,3] and [4,4]

Este comando hace que el socat de mi máquina se conecte a la IP 192.168.1.93 (allí debe estar el servidor), al puerto 31337, y que localmente lo haga ver como un nuevo dispositivo serial (pseudo terminal) creado por socat mismo en /dev/pts/X, y además haga un symlink de éste al archivo /tmp/ttyACM0. A partir de éste momento en /tmp/ttyACM0 existe un archivo que puede ser abierto con pyserial (por ejemplo, puede ser minicom, etc.) y ser utilizado como un dispositivo serie local.

Un detalle, cuando se cierra la conexión del socat en el cliente hacia el servidor, en el servidor también se termina la ejecución del socat (y viceversa), por lo que en caso de volver a establecer la sesión, es necesario ejecutar nuevamente en ambos equipos.

Saludos

Marcelo Fernández: Novedades en SPDY/4, HTTP/2.0

Si bien SPDY/4 todavía está en desarrollo, por lo que se deduce de este hilo y por lo que puede apreciarse en la forma que tienen ambos drafts, éste va a dejar de ser un trabajo separado de HTTP/2.0 como sucedía hasta la versión anterior, sino que será un protocolo que implementará progresivamente lo que se vaya definiendo y ganando adhesiones en la discusión que se está teniendo en el marco del IETF.

Es por esto que además de los cambios previamente definidos para SPDY/4, se le suma un “port” o “sincronización” de características definidas desde HTTP/2.0 hacia SPDY/4.  Los elementos que “se mudan” para desplazar a aquellos definidos en SPDY/3 cuentan con un relativo acuerdo general dentro del HTTPbis WG para ser parte de HTTP/2.0, y son:

  • SYN_STREAM, SYN_REPLY, HEADERS pasan a ser reemplazados por HEADERS+PRIORITY* y HEADERS. Ya había un frame de HEADERS en SPDY/3, pero no se usaban en casos comunes; ahora pasan a eliminarse los frames SYN_STREAM y SYN_REPLY, unificando todas las formas de envío de headers HTTP (ya sea para iniciar/responder peticiones) en el frame de HEADERS que ya existía (entiendo que sólo se le agrega un campo de prioridad). En resumen, en SPDY/4 (y en HTTP/2.0), las peticiones se pedirán y responderán con un frame de HEADERS.
  • Unificaron los frames de RST_STREAM y GOAWAY. Eran redundantes, claramente.
  • Después de ciertas pruebas (ejemplo)(**), ya está definido el magic byte para inicializar una conexión directamente en HTTP/2.0 (o SPDY/4): “FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n”. Pasando en limpio, la idea es que (en principio) haya 3 mecanismos de uso de HTTP/2.0:
    • Vía TLS+NPN, como SPDY/3. De todas maneras, NPN se envió hace unos meses al TLS WG y lo modificaron levemente, dándole forma a lo que se llama ALPN. Para el caso, hará lo mismo que NPN. Claro está, esto funciona sobre SSL/TLS (puerto 443), con sus pros y contras.
    • Si el servidor con el que hablamos no sabemos si soporta HTTP/2.0, se intentaría un upgrade mediante el mecanismo estándar de Upgrade de HTTP, como se hace con WebSockets (ejemplo). Esto funciona sobre puerto 80, en claro.
    • Si el servidor con el que hablamos sí sabemos de antemano que soporta HTTP/2.0, directamente se envía el magic byte luego de establecer la conexión TCP, para comenzar a intercambiar frames HTTP/2.0. La idea es ahorrar el tiempo (valioso) de upgrade. El magic byte está elegido en base a que si lo enviamos por equivocación a un server que sólo soporta HTTP/1.1, éste cause el cierre de la conexión inmediatamente.
    • Hay otras propuestas para ahorrarse el tiempo de upgrade sin saber de antemano si el server soporta 2.0, como publicar el soporte de HTTP/2.0 vía DNS (y así el navegador podría saber si el server habla 2.0 al momento de hacer la resolución DNS), pero por el momento la propuesta está en stand-by.
  • Incluirá control de flujo por stream (además del control de flujo por sesión de SPDY/3).
  • Un algoritmo de compresión de encabezados no basado en el stream completo de éstos, sino basado en cambios (diferencias entre los headers), para evitar los ataques del estilo CRIME. Sobre esto se está trabajando en el HTTPbis WG (principalmente por cosas como el requisito del mantenimiento de estado) y hay dos algoritmos con posibilidades (HeaderDiff y Delta). SPDY/4 incluiría este último.

*: Este frame está en discusión en estos momentos, quizá se defina un nuevo frame PRIORITY para soportar repriorización “al vuelo” de streams.
**: Es interesante comentar que en las pruebas de búsqueda del magic byte realizadas se intentó encontrar un stream de bytes que haga que la gran mayoría de web servers actuales que soporten HTTP/1.1 cierren la conexión inmediatamente o al menos devuelvan un código HTTP de error (4xx). La idea es que si un cliente envía ese stream de bytes, éste se asegure de una respuesta satisfactoria que asegure que el server es HTTP/2.0, y en caso contrario (por error, al suponer que el server soporta 2.0 pero no es así), el efecto producido en el server (y en la comunicación en sí) sea el mínimo posible.

Vamos a ver cómo evoluciona, y si SPDY/4 se hace “estable” en un futuro próximo para poder ir haciendo pruebas. Pero parece ser claro que va a ser bastante diferente a SPDY/3.

Saludos

Hernán Grecco: A Pint a day ...


A few months ago I wrote about Pint, a Python units library that we developed for Lantz. With Pint  you can define physical quantities: the product of a numerical value and a unit of measurement. Pint can convert between units and perform mathematical operation between quantities.

For example:
>>> from pint import UnitRegistry
>>> ureg = UnitRegistry()
>>> my_beer = ureg.pint
>>> print(my_beer.to('liter'))
0.473176473 liter
>>> print(my_beer.dimensionality)
[length] ** 3
>>> ureg.pint < ureg.imperial_pint
True
>>> ureg.pint < ureg.liter
True

As described in the Design principles section of the documentation, units definitions are loaded from a text file which is simple and easy to edit. Adding and changing units and their definitions does not involve changing the code. Prefixed and pluralized forms of units are recognized without explicitly defining them. In other words: as the prefix kilo and the unit meter are defined, Pint understands kilometers. This results in a much shorter and maintainable unit definition list as compared to other packages. Pint also supports advanced string formatting using PEP 3101 syntax. Extended conversion flags are given to provide latex and pretty formatting.

After the previous post, I got valuable comments, suggestions, bug reports and patches. Today we are releasing Pint 0.2 with a lot of nice new features.

Extended NumPy Support

Pint does not require NumPy but provides support for NumPy arrays and functions since version 0.12. You can create a Quantity based on a ndarray:
>>> x1 = numpy.asarray([2., 3.]) * ureg.meter
>>> # or simply by multipliying an iterable by the units.
>>> x1 = [2., 3.] * ureg.meter
Pint 0.2 extends the support to almost all ndarray methods and ufuncs. Each function/method has been tagged according to expected units and how to handle arguments and Pint attempts to convert them on the fly. For example, arctan2 expects two arguments with the same dimensionality and converts the second argument to the units of the first:
>>> x2 = [2., 3.] * ureg.meter
>>> x2 = [300., 200.] * ureg.centimeter
>>> numpy.arctan2(x1, x2)
<Quantity([ 0.5880026 0.98279372], 'radian')>
The cosine function expects a quantity that can be converted to radians:
>>> numpy.cos(x1)
Traceback (most recent call last):
...
pint.unit.DimensionalityError: Cannot convert from 'meter' ([length]) to 'radian' (dimensionless)

Temperature conversion

Support for non-multiplicative (e.g. temperature) units was one of the most requested features. Pint is now able to to convert between different temperature scales:
>>> home = 25.4 * ureg.degC
>>> print(home.to('degF'))
77.7200004 degF

and also supports a multiplicative version for differences:
>>> difference = 5 * ureg.delta_degC
>>> print(difference.to('delta_degF'))
2.7777777777777777 delta_degF

For practicality, the parser infers from the units if you mean a difference or not:
>>> print(ureg.parse_units('degC/meter'))
delta_degC / meter

(of course, you can disable this behaviour if you want)

Pi Theorem

Buckingham π theorem states that an equation involving n number of physical variables which are expressible in terms of k independent fundamental physical quantities can be expressed in terms of p = n - k dimensionless parameters. Pint can find these dimensionless parameters:
>>> result = ureg.pi_theorem({'V': 'meter/second', 'T': 'second', 'L': 'meter'})
>>> print(result)
[{'V': 1.0, 'T': 1.0, 'L': -1.0}]
The returned value is a list containing the dimensionless parameters (in this case only one) each specified using a dictionary. The keys corresponds to the names of the physical variables and the values to the exponents. You can print it nicely using Pint's formatter function:
>>> from pint import formatter
>>> print(formatter(result[0].items()))
T * V / L
or using the dimensions
>>> result = ureg.pi_theorem({'V': '[speed]', 'T': '[time]', 'L': '[length]'})
>>> print(formatter(result[0].items()))
T * V / L 

Measurement

A new class provides provides support for Measurements: a value with uncertainty.
>>> length = (2.3 * ureg.meter).plus_minus(.23)
>>> print(length)
(2.3 +/- 0.23) meter
>>> print('{:.02f!p}'.format(length))
(2.30 ± 0.23) meter
>>> print('The relative error is: {}'.format(length.rel))
The relative error is: 0.1
The measurement class also supports some basic uncertainty propagation:
>>> width = (4.6 * ureg.meter).plus_minus(.23)
>>> print('{:.02f!p}'.format(width / length))
(2.00 ± 0.22)


Interested? Install it and give it a try!

Thanks to the people that contributed bug reports, suggestions and patches. In particular to: Richard Barnes, Alexander Böhn, Dave Brooks, Giel van Schijndel, Brend Wanders

Submit your bug reports, comments and suggestions in the Issue Tracker. There are already some ideas for version 0.3. Check them out, comment and add yours.

Read the docs: https://pint.readthedocs.org/
or fork the code: https://github.com/hgrecco/pint

Gabriel Patiño: Caminata a la cascada

Por suerte a mi vecino (tambíen llamado Gabriel) también le gusta salir a caminar por la montaña, así que el sábado pasado nos fuimos a dar una vuelta por los Altos del Chapelco, donde yo ya estuve caminando y relevando calles para OpenStreetMap.


Cuando llegamos a un puentecito me dice que le habían comentado que siguiendo uno de los caminos se llegaba a una cascada, así que fuimos por ese lado. Al rato encontramos a una pareja paseando el perro y nos dijeron que sí, que era por ahí, pero que íbamos a llegar un poco justos con la luz del sol. Así que le metimos pata.


En total son unos 5km desde casa por calles y caminos (se puede llegar en auto) y después unos 600 metros más siguiendo el cauce de un arroyo seco (supongo que en primavera debe tener caudal) hasta llegar a la cascada.

El agua helada y riquísima.

Los últimos 150 metros son bastante empinados, o eso me pareció por la falta de estado... llegué casi sin aire en los pulmones, así que mejor que me ponga a hacer algo de ejercicio.


Llegamos a la cascada, el lugar más alto a menos que quieras escalar una pared de roca, y la vista desde ahí es muy linda, incluso se llega a ver el lago Lolog. Justo estaba atardeciendo así que todo tenía un color anaranjado especial.

Prueba que la subida era empinada, aparte de no estar en buen estado.
De paso aproveche la salida para probar el nuevo chiche montañero que me compré, funciona muy bien y es una pavada manejarlo. Lástima que confié en pilas chinas baratas bajo la promesa de tener más mAh que las de marca, y me duraron menos de dos horas cuando se supone que tienen que durar 24hs. Voy a tener que recargarlas a pleno y volver a probar... sino quedarán para los juguetes de los chicos.

Con un poco de ganas, arriba a la izquierda se puede ver el Lolog.

Quedó guardado el waypoint para volver en primavera o verano. Si el arroyo tiene agua va a ser un lugar muy lindo para hacer un picnic y chapotear un rato.

Al rato de llegar se puso el Sol, así que tuvimos que bajar rápido.