y yo pense que eramos los unicos

como siempre chateo en el emesene con el debug prendido para ver posibles bugs en la implementacion del protocolo (principalmente MsnP2P), resulta que un contacto me estaba tirando un monton de paquetes P2P seguidos que no tenian sentido, copio algunos para leerlos y veo esto:

<<< MSG lukas.utc@jagermail.com [3^(1/2)_utc]%20(C)%20con%20RosieCoco 465
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: luismarianoguerra@gmail.com

\x00\x00\x00\x00-\xd0\x9f\x00\x00\x00\x00\x00\x00\x00\x00\x009\x01\x00\x00\x00\x00\x00\x009\x01\x00\x00\x00\x00\x00\x00\xfb\x91\x15\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00BYE MSNMSGR:lukas.utc@jagermail.com MSNSLP/1.0
To: <msnmsgr:lukas.utc@jagermail.com>
From: <msnmsgr:lukas.utc@jagermail.com>
Via: MSNSLP/1.0/TLP ;branch={621E96CE-2B17-4DEB-81FA-1670D27565EF}
CSeq: 0
Call-ID: {20CC3166-8288-656E-5EAC-A58212008222}
Max-Forwards: 0
Content-Type: null
Content-Length: 0

\x00\x00\x00\x00

me da curiosidad saber que cliente esta mandando esa calamidad, resulta que es el cliente oficial! WLM 8.1.0178.00.

para los que no leen MsnP2P de corrido :D la cosa es como sigue:
* su cliente me pide que le mande mi Display picture a traves de coneccion directa (Sockets)
* como no lo tenemos implementado, se lo rechazo
* entonces me manda ese mensaje que pegue ahi arriba

que esta mal?

To: <msnmsgr:lukas.utc@jagermail.com>
From: <msnmsgr:lukas.utc@jagermail.com>

eso quiere decir que el mensaje es de el para el mismo (???) para que me lo manda a mi entonces...

Content-Type: null

ayy, acuerdense de hacerle new a los Strings.. sino te sale un null por cualquier lado :D

eso es todo, me parecio gracioso que por la versioin 8.1 de un protocolo definido por ellos no vean esas cosas (debe ser que no chatean con el debug prendido :D)

lectura interesante

estaba leyendo esto: http://dirtsimple.org/2004/12/python-is-not-java.html
mu interesante, voy a resaltar algunas partes..

In examining the code, I found that they had done lots of things that make sense in Java, but which suck terribly in Python. Not because "Python is slower than Java", but because there are easier ways to accomplish the same goals in Python, that wouldn't even be possible in Java.

these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write

The idiomatic translation of a Java static method is usually a module-level function, not a classmethod or staticmethod.

and all those Foo.Bar.Baz attribute chains don't come for free, either. In Java, those dotted names are looked up by the compiler, so at runtime it really doesn't matter how many of them you have. In Python, the lookups occur at runtime, so each dot counts. (Remember that in Python, "Flat is better than nested", although it's more related to "Readability counts" and "Simple is better than complex," than to being about performance.)

Got a switch statement? The Python translation is a hash table, not a bunch of if-then statments

The CPython dictionary implementation uses one of the most highly-tuned hashtable implementations in the known universe.

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."

compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality

There are also other, very rare, architectural reasons to need XML. Trust me, they don't apply to your app. If in doubt, explain your use case for XML to an experienced Python developer. Or, if you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.

admito que desde que programo en python tengo la costumbre de programar setters y getters, me parece que la costumbre va a cambiar.. :D

In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters.

In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.

Buen punto :D

If you find yourself writing the same function over and over again with minor variations, it's time to learn about closures. They're really not that scary.

no, no son para nada "scary"

Essentially, if you've been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python. Take a step back, and above all, stop writing so much code.

tanta poesia en la internes

(ante un post que no viene al caso se produce el siguiente comentario)

[quote]
eso fue tan empalagoso que no te puedo putear



bah, si, puto
[/quote]

tanta poesia.. tan pocas palabras