python 3 reconoce que era dificil, involucion, caso de print y exec

ENGRLISH VERSION IN: qgqlochekone.blogspot.com

los grandes programadores sabemos que sobrecargar uan funcion es menos optimo que redireccionar el flujo de una sitio en la memoria, vease C++ y ">>" versus C ansi.. https://en.wikipedia.org/wiki/Function_overloading#Complications a los que saben programar...

print en pytnon 2 es un statement, algo mucho mas rapido que una funcion, dado la sobrecarga requiere mas ciclos de cpu por ceritifcacion de firmas..

y si creen que el caso de print (ya famoslo pero aqui puesto en argumentos de codigo) tiene que ver el rollo de peo con "exec" jajajaj, el propio Guido van Rossum (the original creator of the Python language) reconoce que nunca hubo un buen script o plan de diseño, y python 3 en incompatible con versiones viejas

PORQUE PYTHON PASO DE redireccion a funcion en PRINT? citase: https://docs.python.org/3.0/whatsnew/3.0.html

la razon es que el diseño inicial de print si bien era util carecia de facilidad, en el enlace "whats new in pyton 3" se reconoce que python NO ES FACIL, y por eso exec y print cambiaron a una forma mas "friendly" ...

.. python su mayor problema es el constante cambio de api, algo terrible para los programadores de proyectos serios y largos, IMPORTANTE CITA: http://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#the-print-function es importante para una consultora que no implemente tecnologias que cambien mucho, esto se termina traducinedo en costes de manpowers... tal como explica el articulo citado..

esto viene a que en mi pequeña consultora estamos montando procesamiento distribuido de multimedia, la primera vez que se realizo esto fue para hacer la pelicula avatar... (no ignorantes no es camaras en red, es un cluster de video) y solo 20 personas en el mundo han podido hacer esto en linux (21 conmigo), el caso es que debido a mi hardware usaremos por motivos de coste (muy justificados) hardware framegraber (zoran 36120) y se requeire una version especifica de landel (software de captura con pip) el cual esta hecho en python 2.6, a los interesados en el proyecto estara en github pero solo bytecodes.. sep software privativo...

1) tenemos:

dom_doc = xml.dom.minidom.parseString(zipfile.ZipFile(sys.argv[1]).open('install.rdf').read().strip())

esto solo funciona en python 3 y queremos que ande en python 2, pero me parecio algo extraño la forma de imprimir en pytnhon 3.. y el erro que arroja si lo uso en 2

2) backportado

zf = zipfile.ZipFile(sys.argv[1])
dom_doc = xml.dom.minidom.parseString( zf.read('install.rdf').strip() )

son mas lineas de codigo, se preguntaran porque.. y cual es la diferencia, en pyton 2 no hay open, pero porque hacer un open si existia read?

3) exlicacion 

si tratas de colocar todo en una linea no hay problema SOLO SI las lineas anteriores son especificamente ajenas a un condicional con un print por funcion, y ejecutas en python 2.5 o 2.6 el error que arroja es de identacion.. (python cambia las llaves por identacion) ESTO FUE UN ERROR DE DISEÑO en python.. corregido en pytnon 3.2 ya que las versiones 3.0 nunca se recomendaron como api estable (uff otra vez eso de andar cambiando cada rato)

ORIGEN DEL PROBLEMA EXTRAÑO: sobrecarga vs reasignacion, involucion

en ptyhon print cambia (ah cambio que raro) entre 2 y 3 ahora print es una funcion (sobrecarga de funciones, no disque es menos optimo, bueno...) y por ende da error de identacion.. lo que te lleva a backportar la linea que imprime asi:

a) de python3 (actual) : print("hola", file=pepe.txt)
b) a python 2 (deprecated) : print >> pepe.txt, "hola"

segun no recuerdo muchos programadores citan que sobrecarga de funciones no es ideal, reduce el rendimiento por la firma de la misma, el ejecutor del bytecode necesita revisar si cumple con la firma de la funcion, esto lleva tiempo de ejecucion en cpu, haciendo mas lento...

entonces echamos para atras, incolucionamos en pytnon 3 al cambia redireccion de flujo (c++ like) a sobrecarga de funciones?]??? seee... inteligentes no? ufff

la llamada 1 el metodo open simplemente permite "saltar" este ERROR DE DISEÑO EN PYTHON y esta es la verdadera razon.. no puedes llamar a read sin cerrar el flujo abierto previamente.. y en la llamada anterior open y depsues read solucionaba este problema..

con esta llamada en el api se permite lamar todo en una sola linea y acceder al objeto como todo lenguaje orientado a objeto debe.. 

PORQUE DEBO USAR ALGO VIEJO, para ahorrrar casi medio milon en ganancias..

PORQUE? porque dentro de algunos de esos srpm's hay pedazos de codigos (parches) que permiten mexclar soporte para mexcla de versiones, ejemplo

zipfile.zipfile en python (todos sabemos que python es una basura, esto lo demostrara) cambia entre todas las versiones..
en 2.4 no tiene open, solo read a bajo nivel, hay que primero decomprimir a un objeto archivo y despues es que haces read buscando el archivo al cual read
en 2.5 no tiene open, tiene read y ya se puede referenciar mas de una vez (sep, no puedes hacer read y volver hacer read que porqueria)
en 2.6 ya tiene open y puedes abrir directamente el archivo sin descomprimir todo, sino que busca directo y te da un objeto file de una para read
en 2.7 igual que la anteriro, pero se me olvido decir que debes tener import from future... 
en 3.0 raramente no esta, no me estraña estaba "definiendose) bueno la 3.0 fue uan version de muchos problemas
en 3.2 ya esta normalizado el api y hasta ahora no hay cambios, pero tranquillos, no los decepcionara y apenas terminen de aprender ya habra cambiado el api jajajaj

bueno despues de burlarme del peor lenguaje del mundo, no me extraña sea el mas usado, el populacho nunca sabe lo que quiere...

entre estos encontre como portar ese preciso metodo:

nuevamente le explico a los que no saben..

porque tengo unas tarjetas de alto rendimiento que usan el chip zoran 36120 muy adecuadas para esto, Y NO FUNCIONAN EN LINUX NUEVO, su modulo fue removido en 2.6.19

 y no voy desperdiciar 6 tarjetas capturadoras por lengujes de programacion estupidos y modas de usar lo ultimo, dinero mata moda .....

una capturadora framegraber pcie cuesta en cambios hacia este pais (al 2016-12) casi un millon en moneda local, me ahorro mucho dinero vendiendo algo que solo yo manejo asegurando trabajo solo para mi gente.. y no que venga otro a quitarlo..

verdadero espiritu capitalista para los que les gusta eso..

bueno queda un anio para dicho proyecto.. que basura es un mal diseño.. no me extraña, intel esta detras de esto..

FUENTES DIRECTAS

Estas fuentes demuestran la gran inestabilidad en usar python, clasificado como el lenguje que mas cambia su api, se parece a microsoft jajajaja


Lenz McKAY Gerardo (PICCORO)

Comentarios

Entradas populares de este blog

canaimitas: modelos (info mas completa)

Boton parpadeante canaimitas EF10MI2 FALLAS comunes

Destripando el instalador debian para usuarios medios.