"Steal This Software"

Cloud.obj - Objetos Python en la nube

2012-04-10T15:50:00.006-07:00

Primero que nada, un poco de historia. Estaba pensando: Se pueden importar módulos que estén en un servidor remoto? Y, si es sí, se puede hacer fácil, con poco código y, portable?

Todo eso, en Python, fue un SI.

La idea es, Cloud.Obj es un repositorio de modulos de Python, de donde todo el mundo puede hacer sus "imports", sin modificar demasiado el código que usarían para importarlo localmente.

Lo único que se necesita es bajar un modulito, "cloud.py" y ya está listo para usar, sin dependencias ni nada más extra.

Aquí, un ejemplo de uso:

#A simple, example
import cloud
o = cloud.Obj("http://cloudobj.appspot.com/sys") #o is the module sys
print "The path is ", o.path
print o

Por supuesto, si picara la curiosidad o si, simplemente, quisieran montar su propio servicio, el código del "server", también está en GitHub, listo para que lo bajen, en sus versiones "Servidor local" y "listo para deploy en GAE"

Más adelante, tendrá dos sabores:

Public Repo: Módulos importables públicos, para todos.
Private Repo: Con login, para quienes quieran subir código importable, protegido con password.

Cabe aclarar que, si bien hablo de repositorios, la idea no es ser un github, sino, un lugar común y en la nube, desde donde importar la última versión del módulo X.

Aquí los links:

Servicio en GAE
Download
GitHub

Y, cómo siempre, se aceptan ideas, críticas y quien quiera participar, bienvenidisimo!

Django-IDE: Ahora en GitHub!

2011-12-11T15:42:00.000-08:00

Ya está subido el código de lo que hay hasta ahora, de la IDE que estoy cocinando:

Introducing: Django-IDE

Hay mucho por hacer y mucho por mejorarle, por lo que, colaboradores bienvenidos!

Django-IDE: Video preview

2011-10-25T16:36:00.000-07:00

Luego de escribir este post IPnaf IDE - La IDE definitiva para python, y recibir algunos comentarios que me hicieron pensar (y ver que, estaba un poco equivocado en mis comentatios), me dije "y por qué no puedo ser yo quién arme una IDE?"

Y así fue que, pensando un poco, me puse a intentar llenar un hueco que, creo que está lo suficientemente vacío como para que un esfuerzo allí, valga la pena.
Entonces, empezó a nacer Django-IDE.

Les dejo un video con una preview muy muy muuuuy temprana (no tiene para nada todos los features que va a tener), en fin, acá va:

Ver en youtube

What is Django-IDE good for?

Django-IDE helps you to:

Easily create Django projects.
Manage and edit existing project
Edit and Save your code, with a editor based on Ace.
Run and debug.

La estoy armando a pulmón, esto es, codeo un poco los findes, y cuando puedo...
Espero comments!!! :)

IPnaf IDE - La IDE definitiva para python

2011-10-07T20:08:00.000-07:00

Dentro del titulo mentiroso, que usé para atraer la atención (el plan B era poner "cerveza gratis!") encierro un pensamiento mío, pero que creo que muchos compartimos. Pero, primero lo primero:

IPnaf IDE quiere decir: IPnaf Please Not Another Fucking IDE!!

Aunque, debería ser "not another fucking python IDE!" Y a qué me refiero con esta misteriosa frase?? He visto, y ultimamente mucho mas, una proliferacion de lo que hacen llamar IDEs. Pero, me voy a centrar en IDEs para el lenguaje pythyon: cito, spyder, Ninja, entre otros, que aparecieron como "somos la IDE definitiva".

Hay un chiste de Xkcd donde, la idea más o menos es que, alguien dice "uh, hay n maneras de hacer x! No puede ser, hay que generar un standard. Horas luego hay n+1 maneras de hacer x"

Y es así. Siempre. Siempre?? Bueno, no siempre, pero en el 99.9% de los casos. Otras veces, ese pensamiento da lugar a innovaciones. Pero, es lo común?? Diríamos que no.

Vuelvo a los ejemplos que cité: Spyder y Ninja. Ambas las bajé, instalé y probé. Aclaro que no tengo nada en contra de quienes la desarrollan (ni los conozco) ni me parece que su trabajo y esfuerzo sea malo. Al contrario. Pero, veo que está desperdiciado. Gente con talento claro, pone esfuerzo en cosas que ya existen y, sin innovaciones reales. A qué me refiero??

Spyder y Ninja [0] son, sin duda esfuerzos de desarrollo y diseño. Pero, que son? Editores de texto lindos y python friendly. Nada más. Ah, y que ejecutan código. Nada que no puede hacer con Emacs y un poco de tiempo + macros.

Debugger? No, gracias. [1]

Ojo, no es que sea fácil hacer un debugger como la gente, que corrar el código paso a paso y podamos inspeccionar varibles, ejecutar código en el contexto de ejecución, editar código on the fly, hacer remote debugging etc. [2]
Pero, es lo que falta!! (en general) Y si, es más lindo ponerse a escribir la IDE desde cero [3], y luego agregarle esas funcionalidades superstar, pero, primero hay que hacer el editor, el highlighter, el buscador de código, el generador de plugins, el pseudo intellisense, etc. Y, para cuando llegamos a las funcionalidades breakers, rockstar, "la papa", quizá el proyecto ya murió.

"No necesitamos esos features de maricones". Diría el macho programmer. (y esto me hizo acordar a otro chiste de Xkcd) pero, la realidad es que, cuando más cómodo esté uno, mejor trabaja y más se puede concentrar en el problema puntual que esté resolviendo.

Por qué no tomar una IDE existente y opensource y mejorarla en vez de arrancer una from scratch?

Entonces, si se van a poner a programar, aviso, no necesitamos más IDEs =)

EOF

[0] Elegí Spyder y Ninja porque son 2 que recuerdo haber visto últimamente, y que además las instalé y probé.

[1] Creo que Spyder estaba implementando pdb y winpdb. De todos modos, mi punto sigue en pie.

[2] Acá es cuando alguien me va a decir, "vos, porque estás acosbumbrado a visual basic" Puedo asegurar que he programado en editores de texto plano como en Visual Studio, Eclipse o Netbeans. Uno puede usar un debugger o usar prints, pero, las funcionalidades rock star en las IDEs, son geniales!! No es que uno no pueda vivir sin ellas, pero, si existen, mucho mejor!!

[3] Es como el caso de las n distribuciones de Linux. Ya hay suficientes en variedad como para parar un poco, si tenés tantas ganas de laburar en una distro, contribuí con una que exista!!!

Volvi a programar en mi "spare time": web_alert - Parte 2

2011-07-14T16:19:00.000-07:00

En un post anterior, estuve contando sobre un proyectito que arranqué, por puro hobbie pero, esperando que sea útil a la vez.

La cosa es que me encontré con algo que me desaminó un poco: http://www.webalertpro.com/

Primero, es casi exactamente la misma idea.
Segundo, tiene casi el mismo nombre!

Obviamente, esto es culpa de mi, evidente, falta de inventiva.

Por ahora sigue el proyecto, pero lamentablemente, perdió un poco de empuje.

Volvi a programar en mi "spare time": web_alert

2011-06-28T17:16:00.000-07:00

Proyecto: web_alert
Objetivos: Divertirme, aprender y, en una de esas, sale algo útil.
Lenguajes: Python, obvio!

Queriendo meterme un poco con python+web, empecé un proyectito al que nombré "web_alert".

Primero lo armé versión consola y "on demand", luego la idea es que sea una especie de servicio web.

Qué haría? Fácil, toma como input urls que el usuario suministra y tags de interés que el usuario suministra, por ejemplo:

urls: http://barrapunto.com, http://www.lanacion.com.ar
tags: panchos, celulares, perros

La aplicación 'mira' esas urls, y genera como output links relacionados con los tags que le pasas como input y, te lo presenta donde vos le digas, por ejemplo:

mail, twitter, facebook.

Sirve? No se, pero que me voy a divertir, seguro. =)

P.D: Previews y el código en google, coming soon...

EDITADO: Este post estaba en planeta python y desapareció, jua! =)

Advide from an old programmer

2011-06-16T16:04:00.000-07:00

Advice From An Old Programmer

You have finished this book and have decided to continue with programming. Maybe it will be a career for you, or maybe it will be a hobby. You will need some advice to make sure you continue on the right path, and get the most enjoyment out of your newly chosen hobby.
I have been programming for a very long time. So long that it is incredibly boring to me. At the time that I wrote this book I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were. Eventually though this just became boring and couldn't hold my interest.
What I discovered after this journey of learning is that the languages did not matter, it's what you do with them. Actually, I always knew that, but I'd get distracted by the languages and forget it periodically. Now I never forget it, and neither should you.
Which programming language you learn and use does not matter. Do not get sucked into the religion surrounding programing languages as that will only blind you to their true purpose of being your tool for doing interesting things.
Programming as an intellectual activity is the only art form that allows you to create interactive art. You can create projects that other people can play with, and you can talk to them indirectly. No other art form is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes both ways.
Programming as a profession is only moderately interesting. It can be a good job, but if you want to make about the same money and be happier, you could actually just go run a fast food joint. You are much better off using code as your secret weapon in another profession.
People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.
Of course, all of this advice is pointless. If you liked learning to write software with this book, you should try to use it to improve your life any way you can. Go out and explore this weird wonderful new intellectual pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you can.
Finally, I will say that learning to create software changes you and makes you different. Not better or worse, just different. You may find that people treat you harshly because you can create software, maybe using words like "nerd". Maybe you will find that because you can dissect their logic that they hate arguing with you. You may even find that simply knowing how a computer works makes you annoying and weird to them.
To this I have one just piece of advice: they can go to hell. The world needs more weird people who know how things work and who love to figure it all out. When they treat you like this, just remember that this is your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that you have picked up a skill they never in their wildest dreams could acquire.
You can code. They cannot. That is pretty damn cool.

Fuente

Framework web minimo

2011-06-01T16:45:00.000-07:00

Estaba buscando algún framework web, chiquito y sencillo. Quería tirar código y que salga andando algo, fácil, sin instalar mucho ni configurar.
Se me ocurrió preguntar en la lista de python argentina[0].
Al instante, muchas respuestas y, una de ellas me nombraba web.py (que lo conocía) y otro más[1], que es el motivo de este post:

Muy zarpado. Lo primero que me cautivó:

"Bottle does not depend on any external libraries. You can just download bottle.py into your project directory and start coding."

Un solo archivo! Lo importo y, habemus web. Eso es lo que quería!

Luego, el hello world:

from bottle import route, run

@route('/hello')
def hello():
    return "Hello World!"

Cada vez se ponía mejor. Sintaxis clara y, una linda manera de resolver la relación url-código: Decoradores.

Creó que me enamoré =)

[0] PyAr
[1] Bottle

Magia Negra: Un ActiveRecord en pytnon

2011-03-10T15:44:00.000-08:00

~~Pensando en un proyecto cuasi muerto que tengo, me vino a la mente que, aprovechando el código ya escrito y con muy poco esfuerzo/código más, puedo armar un framework que implemente ActiveRecord~~

~~Y acá está (solo está creado el espacio y subido un commit inicial) pero promete.~~
~~El nombre, inspirado en el efecto mágico y, un tributo a las viejas bandas del metal quizá?~~

Status: Muerto por falta de interés.

Quick Hack

2011-01-31T13:06:00.001-08:00

Tenia que resolver lo siguiente:

Una macbook que baja mails desde un servidor propio (con un Kerio en la empresa)

Un router que no soporta loopback

Entonces, cuando la mac esta fuera de la empresa, se podia hacer referencia, en el cliente de mail, al DNS, que llamaremos empresa.dyndns.ws (para no revelar datos reales)
Pero, dentro de la empresa, el DNS empresa.dyndns.ws, simplemente no funciona.
Habia que resolverlo, y rapido[0].

Python al rescate!
Colorized Source Code

He aquí el script (es feo, muy feo, pero salio rapidisimo y con fritas!)

import os

from subprocess import Popen, PIPE, STDOUT

esta = False

p = Popen(['ping','-c','1','server'], stdout = PIPE)

output = p.stdout.read()

p.wait()



if 'bytes from' in output:

    ok = True

else:

    ok = False



f = open('/etc/hosts', 'r')

f2 = open('/etc/hosts2', 'w')



for i in f:

    if 'empresa.dyndns' in i:

        esta = True

        if ok:

            f2.write(i)   

    else:

        f2.write(i)      



if not esta and ok:

    f2.write('192.168.0.1    empresa.dyndns.ws \n')	





f.close()

f2.close()



os.remove('/etc/hosts')

os.rename('/etc/hosts2','/etc/hosts')

Basicamente, hace un ping al nombre del servidor donde esta el servidor de mail (el Kerio) con el nombre local, 'server'. Si esta, estoy en le empresa, sino, no.
Entonces, basado en eso, toco el archivo hots (gracias Apple por hacer su OS un UNIX) y listo[1]. Se agrego al inicio y se corre con permisos de root y logramos lo que esta persona queria, una solucion rapida y magica.

No estoy orgulloso del script en si, sino, del poder de python para hacer estos quick hacks, que te salvan la papas. =)

[0] Dicen que rapido y bien, es imposible.
[1] Pero, como decia TuSam, puede fallar. Por ejemplo, si justo hay otro 'server', donde esta esta persona (shit happens)

Programar: Ensuciarse hace bien

2010-11-06T15:01:00.000-07:00

A quienes hayan podido ver en "la caja boba" la publicidad de una conocida marca de productos para lavar la ropa, les sonará esta frase con la que titulo esta entrada:

"Ensuciarse hace bien"

Lo que quizá no se entienda es por qué la adopto, o qué puede tener que ver con la programación.

La historia

Brevemente, y para no aburrir a quienes ya conocen el aviso, trata de unos niños jugando, ensuciandose y de cómo eso es beneficioso para estos chiquitos. Obviamente, el ensuciarse beneficia a la marca, pero ese es un tema aparte. Lo que me interesa es el concepto:

jugar + ensuciarse + cansarse + ensuciarse de nuevo = beneficio

Esto es muy cierto y, creo que se aplica a la programación. No es que me haya dado cuenta de golpe, pero, algo que experimenté hace unas horas, hizo que me inspire y escriba esta entrada.

Estaba (y estoy) escribiendo una mini-nano-IDE en python+pyqt4. Lo que hace es levantar una ventanita gráfica muy simple con un editor de texto con highlighter de sintaxis de python y, lo más interesante, quería que tuviera un debugger.

Entonces, me puse a leer. ¿Cómo demonios hago un debugger? Obviamente, nunca pensé escribirlo desde cero, no es la idea reinventar la rueda (más allá de que sería interesante) por lo que, caí en lo más básico que se me ocurrió, Pdb.

Y acá empieza todo el tema del juego: comencé a jugar con la clase, probé como funcionaba (hacía mucho que no la usaba y no recordaba los comandos) y estuve así un rato. Después, leí un poco de la documentación como para ser un poco más prolijo.

Luego, empecé a escribir códigos de prueba, donde heredé la clase, y seguí jugando un poco más.

Luego, usando mi editor de texto favorito (¿cuál será?) abrí el módulo pdb.py, y me lo puse a mirar. Ahi noté que, la clase Pdb heredaba otras dos clases: cmd y, la más interesante, Bdb que, no era otra cosa que un framework para implementar debuggers!! Así que abrí también el módulo bdb.py y me puse a leerlo, junto con un poco de la documentación.

Pero, estaba avanzando lento, quería realmente zambullirme de lleno, quería experimentar con el código un poco más, involucrarma más, en fin, quería ensuciarme.

Así que: ¿que hice? Cómo tampoco la idea es romper (sobre todo, bibliotecas estandard) me copié el módulo como pdd.py a la carpeta de mis scripts y, ahi, con una copia del pdb.py original, me arremangué y metí los dos brazos de lleno en el barro y la mugre.
Y me puse a chapotear: Agregué prints con estados (que forma moderna de debuggear, ¿no?) cambié cosas, saqué otras cosas más, agregué atributos y métodos nuevos a la clase, sobreescribí algunos métodos originales, en fin, toqué el código como si fuese mío y, en cierto sentido, lo hice mío, me sumergí y salí, tiempo después, escupiendo código python (es sólo una metáfora) y, lo más importante, terminé de definir cómo voy a hacer el debugger usando, la clase original pdb (y no su versión diezmada por mí)

Moraleja

Y, luego de todo esto, ¿cuál es la moraleja?
La moraleja es que, cuando uno quiere entender algo que, como en este caso, es código ajeno y es un tema nuevo para uno, no alcanza con leer el código y la documentación.
Uno tiene que, apropiarse del código, meterle mano, cambiarle cosas, ensuciarse de él. Haciendo esto, uno logra entender de forma más profunda, e incluso, más rápida, el código ajeno.

Así que, la próxima vez que quieran entender código ajeno, ya se una biblioteca estandar, una biblioteca de terceros o, simplemente, el módulo que escribió tu compañero de trabajo, no tengas miedo de mirar el código, ejecutarlo, tocarlo (haciendo una copia, claro) porque, como dije al principio:

"Ensuciarse hace bien"

Client side Python

2010-09-20T18:42:00.000-07:00

El pasado sábado 18-09, estuve en la Mozilla SFD y, en una de las charlas me enteré de un proyecto llamado DrumBeat.

Es realmente interesante: Basandose en el objetivo de Mozilla de mantener y ayudar a que la web sea cada vez más abierta, lo que proponen es un sitio donde se agrupan proyectos, ideas, sobre cosas que ayuden a que esto pase, es decir, a que la web sea cada vez más abierta.
Pueden ser proyectos de todo tipo, no tiene que ser necesariamente relacionado con programación.
La idea detrás de DrumBeat es conseguir apoyo y financiación de estos proyectos, con el fin de, claro está, concretarlos.

En fin, el día de la charla hubo un brainstorming y, me quedó el tema dando vueltas en la cabeza. En el camino de vuelta, se me ocurrió algo:

Un Python, Client-Side. =)

La idea es, para el desarrollo web, lo que es Server-Side, uno tiene alternativas, entre ellas, python, php, perl, ruby, etc. Pero, para el lado del cliente no hay tantas. Basicamente, javascript y, luego empezar a dar vueltas por soluciones oscuras, plugin-dependientes, etc.

Qué bueno sería tener más lenguajes disponibles para los scripts del lado del cliente, no? Y no sería genial arrancar por (a mi entender) el lenguaje más cómodo, amigable, divertido y, a la vez, poderoso del universo???
Así que armé el proyectito:

Client-Side Python en DrumBeat

Creo que la idea en si, no es mala... Obviamente, lo que necesita es notoriedad!! Por lo que, unos votos no le vendrían nada mal!

VbAutodoc: Auto documentando VB

2010-08-21T15:48:00.000-07:00

Qué lindo sería contar con una herramienta que, lea el código fuente (en este caso en VB) y me arme un archivo de documentación sobre las funciones y sub rutinas (preferentemente en html).
Cómo soy programador y me gusta python =) decidí hacerla. La bautizé vbautodoc (muy original) y está disponible una muy ~~precoz~~ temprana versión.

Próximamente, voy a mejorar aspectos en cómo se construyó, por ejemplo, el pedazo de html que uso como base, lo metí dentro del código, y sólo funciona para documentar VB, cuando, si se parametriza podría servir para cualquie lenguaje.

Web del proyecto
Descargas

Top 5 tips para desarrollar mejores aplicaciones

2010-06-19T14:24:00.000-07:00

Muchas veces me pongo a pensar en retrospectiva, acerca de cosas que se han hecho bien y cosas que se han hecho mal. Aquí escribo un resumen de las principales cosas que recomiendo hacer para ser un programador más feliz.

1- El usuario no tiene tiempo, ni quiere leer.

Olvidense del RTFM. Nadie lo lee. Hay que imaginarse que el usuario está inmerso en un caos tremendo, teléfonos sonando, gente, alarmas, etc. Lo que menos quisiera es estar lidiando con carteles del tipo "está seguro que desea cerrar etc", o, con aplicaciones oscuras que, si bien hace lo que se debe, tienen muchos botones, radio button y demás, y que, ni el mismo desarrollador entiende sin mirar el código.
Por eso, las aplicaciones tienen que ser intuitivas, se tienen que "auto-explicar". Lo mismo se aplica para los carteles y pop-ups que requieren una decisión del usuario. Si no hay más remedio que poner un cartel, que sea corto y puntal. Por ejemplo:

¿Está seguro que desea cerrar la aplicación?
[si] [no]

Cuando se podría:

¿Salir?
[si] [no]

Mucho más corto y al pie.

Por último, recuerden la página de Google, un cuadro de texto y un botón. ¿Qué mas?

2- Refactorizar vs From Scratch.

No siempre es bueno reescribir todo, ni tampoco siempre lo es reusar. Hay que usar esto de forma inteligente. Por un lado el código viejo no es necesariamente malo o confuso. Hay que tener en cuenta que, por un lado, leer código es más dificil que escribirlo (por eso siempre es tentador el reescribir todo) y por otro, el código viejo es, muchas veces, un código ya testeado, con bugs correjidos, en fin, es tiempo de trabajo. Reescribir todo desde cero significaría, tirar todo eso a la basura.
Lo ideal es un balance entre, reescribir las partes "mal escritas" tratando de reusar lo más posible. Es significativamente menos tiempo que escribir todo desde cero, sobre todo, si tenemos en cuenta que, el código desde cero va a tener bugs nuevos.

3- Pensar en grande.

Todo buen programa tiene que empezar cómo algo simple, pero, pensado a lo grande. Esto es, pensar que en un futuro, el programa puede crecer. Por eso, hay que escribir todo de forma flexible, aunque lleve más tiempo ahora, en un futuro va a ser más facil expandir y mantener. Mucho se ha hablado de la deuda técnica.Esto es un poco lo que trato de comunicar aquí: El tiempo que se ahorra escribiendo código chapucero ahora, lo pagás mañana.

4- Keep it simple.

Muchas aplicaciones tienen varias faces de desarrollo. Esto es, se reune con el cliente, se diseña, se programa, se vuelve a ver con el cliente, se corrijen cosas, se agregan otras. Entonces, es de esperar que el cliente no sea muy lógico, que haga cambios sobre la marcha y que no tenga en cuenta el diseño general del sistema. Para eso nos paga a nosotros ¿Verdad? Por eso, siempre hay que hacer limpieza del código y del programa. Lo que no se usa, fuera (por lo menos, de la vista) Esto ayuda mucho a que se cumpla el punto 1.
Si la aplicación en si, estaba pensada con otro espiritu y luego, se modificó, tratar de quitar todo lo que sobre. A veces más es menos. Muchos botones y radio button, checks, etc, para mantener un poco la idea anterior y que conviva con la idea nueva genera más problemas que soluciones. Use it or lose it.

5- Testing

Esto es obvio, pero, no se respeta mucho. El cliente no es un beta tester. Si se programa con la idea "que tenga bugs, total lo corrijo rápido" se arriesga, primero, problemas en datos que haya que resolver (esto es tiempo) y, segundo, da la idea de que el programa anda mal.

Octopys: Octopus para linux

2009-12-13T18:17:00.000-08:00

Algún día prometí que iba a hacer una versión de octopus para linux, y cumplí. Por lo menos, ya hace algo, habrá que pulirlo un poco, lógicamente.

Está escrito en Python, con una GUI en Qt y lo pueden descargar desde acá.
O, pueden mirar el código directamente gracias a pastebin:

main.py
oct.ui
octo.py

El funesto caso de Is y ==

2009-12-12T08:01:00.000-08:00

Hace varios días (creo que pasaron meses) inicié una discusión en la lista de mail (creo yo, más famosa y con más gente que sabe en serio) de python. PyAr.
La cosa empezó por un artículo que leo, donde se mostraba lo siguiente:

>>> a = 10
>>> b = 10
>>> a == b
True
>>> a is b 
True

Luego

>>> a = 500
>>> b = 500
>>> a == b
True
>>> a is b
False

Claro. Al ser relativamente nuevo en python, ver esto me sorprendió, por lo que decido preguntar de que se trataba en la lista.
Mi pregunta no fue del todo clara, (y acepto 100% la culpa) por lo que se entendió que mi sorpresa venia por una confusión de conceptos y que, lo que no sabía era la diferencia entre "is" y "==".

Lo que pasó:

En realidad, yo posteo todo el ejemplo (que incluye "is" y "==") para dar un contexto, pero, en si, mi sorpresa venía SOLAMENTE por ver como el operador "is" se comportaba aparentemente distinto en dos situaciones aparentemente iguales.
Noten el uso de aparentemente. Esto es:

 [entero_valor_x] is  [entero_valor_x]

True

 [entero_valor_Y] is  [entero_valor_Y]

False

Olvidemos que comparar enteros con "is" es una chanchada, es incorrecto y no tiene mucho sentido. Más allá de eso, no me parecía (noten que uso el tiempo pasado) que comparar enteros (del mismo valor numérico) con "is" resultara True en algunos casos y False en otros. No veia el por qué, y me parecía feo (noten que sigo usando el pasado).

Pero claro, como se interpretó mal mi pregunta, todo se enfocó a explicarme que "is" no era "==", lo cuál, no era PARA NADA el punto del topic.
Claro, fue mi culpa por no ser claro en una primera instancia. Luego, traté de remediarlo, pero ya era tarde y... el resto es historia.

La explicación:

La explicación la había encontrado muy al comienzo del thread. Posteo una que me gustó y es sencilla:

Autor: Facundo Batista
Fecha: 2009-11-04 12:192009-11-04 15:19 -300UTC
A: pyar
Asunto: Re: [pyar] WTF?

a apunta a un 3 en memoria, y b apunta al mismo 3 en memoria. Python
no creó dos objetos "3", sino que usó el mismo para los nombres a y b.

a apunta a un 500 en memoria, y b apunta a otro 500 en memoria. Python
sí creó dos objetos "500".

La pregunta es... ¿por qué la diferencia de comportamiento? Como bien
dijo Nati arriba, Python precachea (o tiene internalizado) algunos
enteros chicos, porque sabe que siempre se van a usar.

Esa es sólo una, varios usuarios lo explicaron muy bien también. =)
Y eso era todo lo que quería escuchar. Una explicación sobre el funcionamiento, en apariencia, raro del "is" comparando enteros. No que me digan que usar "is" en ese caso estaba mal (cosa que sabía) ni que "is" no es "==" (cosa que sabía), y un largo etc.

CodMACs/Python

2009-10-15T18:49:00.000-07:00

Finalmente, subí a code.google la primera versión de CodMACs (implementación escrita en python) la pueden bajar desde acá.

El zip tiene clave. La idea es tener un poco de control sobre quién bajó el script. Todavía no estoy utilizando el sistema de control de versiones que provee google.

Quién desee la clave, me puede enviar un mail a mi dirección hosteada en gmail: martincerdeira.

Edito:

Nuevo blog dedicado: http://www.codmacs.blogspot.com/

Porqué Python?

2009-08-10T17:28:00.001-07:00

Python es un lenguaje sencillo y versátil que todo el mundo (inclusive quienes no trabajen directamente en programación) debería conocer.
Posee:

- Sintaxis limpia y sencilla. Esto hace que sea rápido desarrollar reduciendo los tiempos y la cantidad necesaria de programadores. Es ideal para escritura de scripts rápidos.

- Baterías incluidas: Tiene una enorme biblioteca estándar lo que hace que el trabajo sea más veloz y sencillo.

- Multiparadigma.

- Poderoso y robusto.

- Su identación obligatoria hace que la claridad de los programas resalte.

- Usado en conjunto con bibliotecas gráficas (como GTK+ o Qt) es posible armar proyectos grandes que incluyan GUIs.

- Portable. Es posible ejecutarlo en, por ejemplo, Linux, windows y Mac, Windows Mobile, y Google Android (gracias Fisa)

- Documentación altamente disponible: 1) En internet (muchas páginas y wikis incluyendo oficiales y no oficiales) 2) Listas de correo (como pyar) donde hay un feedback constante. 3) En el mismo modo interactivo.

- Una comunidad excelente en Argentina (gracias Facundo) http://www.python.org.ar

Creo que esas son las principales.
La pregunta es, todavía no probaste python?

Conjetura de Collatz:: 3n+1

2009-07-29T15:29:00.000-07:00

Explicación

Por si no les dió ganas de leer, basicamente lo que expone es que dado un numero entero positivo cualquiera (n), si se le realizan una serie operaciones sucesivas (si el nro es par, se lo divide por 2, caso contrario, se lo multiplica por 3 y se le suma 1) el resultado siempre es 1.
Ejemplo:

{7,22,11,34,17,52,26,13,40,20,10,5,16,8,4,2,1}

Una vez alcanzado el 1, no se continúa ya que quedaríamos en un loop ya que 1 es impar y:

1 * 3 + 1 = 4
4 / 2 = 2
2 / 2 = 1
1 * 3 + 1 = 4
etc
etc

Hasta la fecha no se ha demostrado.

Dejo un script en python que (si bien no lo demuestra) sirve para jugar un rato probando con distintos números.


def syracusse(init):
   print "<--START (" + str(init) + ")"
   syr = init
   while syr != 1:   
       if syr % 2 == 0:
           syr = syr / 2
       else:
           syr = (syr * 3) + 1       
       print syr
   print "<--END"

Autodocumentación

2009-07-27T14:29:00.000-07:00

Algo muy bueno y que realmente puede ser muy útil en python es la autodocumentación.

Realmente no requiere demasiada explicación, solamente es necesario ingresar un comentario del tipo (""") al comienzo de nuestra function (debe estar identada) y luego, invocando el comando help() pasandole el nombre la función veremos ese texto. Ejemplo:


def autodoc(msj):
  """Ejemplo de autodocumentacion
      parametros: msj = Mensaje a mostrar"""
  print msj
help(autodoc)

Vamos a ver algo asi:

Help on function autodoc in module __main__:

autodoc(msj)
····Ejemplo de autodocumentacion
····parametros: msj = Mensaje a mostrar
(END)