Probando la interfaz de HelloTxt con gtalk
-
-
Uso del tipado dinámico en Python
- Traducción de The History of Python - Python's Use of Dynamic Typing
- Publicado originalmente por Guido Van Rossum, el jueves, 10 de febrero de 2009
Una diferencia importante entre ABC y Python es la esencia general del sistema de tipos. ABC es un lenguaje de tipado estático, lo que significa que el compilador de ABC analizaba el uso de los tipos en el programa y comprobaba si eran usados de forma consistente. Si no era el caso, se rechazaba el programa y nunca se llegaba a ejecutar. Al contrario de la mayoría de lenguajes de tipado estático de la época, ABC usaba inferencia de tipos (No muy diferente de Haskell) en vez de declaraciones explícitas del tipo que puedes encontrar en lenguajes como C. Python, por el contrario, tiene tipado dinámico. El compilador de Python no se ocupa para nada de los tipos de datos usados en el programa, y todas las comprobaciones de tipos se realizan en tiempo de ejecución.
Aunque esto puede parecer una gran diferencia con ABC, no lo es tanto. Al contrario que otros lenguajes de tipos estáticos, ABC no depende (¿o dependía? es en su mayor parte historia a fecha de hoy) exclusivamente del chequeo de tipos estático para evitar que el programa fallara, también tenía una librería en tiempo de ejecución que comprobaba los tipos de los datos pasados como argumentos en todas las operaciones, cada vez que se ejecutaban. Esto se hizo en parte como complemento de seguridad para los algoritmos de comprobación de tipos del compilador, que no estaba completamente terminado en los primeros prototipos. La librería también resultaba ser de gran ayuda en el depurado de errores, ya que las comprobaciones realizadas en tiempo de ejecución pueden proporcionar mensajes de error muy buenos (una de las metas del equipo de desarrollo), en vez de los volcados de memoria que se producirían si el interprete intentara la operación a ciegas, sin comprobar los parámetros.
En cualquier caso, la razón más importante para que ABC tuviera comprobación de tipos en tiempo de ejecución, además de la realizada en tiempo de compilación, era su naturaleza como lenguaje interpretado. En una sesión interactiva, el usuario teclearía sentencias en ABC que serían ejecutadas tan pronto como se pudiera. El usuario podría crear una variable como un número, borrarla y luego recrearla (es decir, crear otra variable con el mismo nombre) en forma de cadena de texto. Dentro de un procedimiento se produciría un error por usar la variable primero como si fuera un número y luego como si fuera un texto, pero no era razonable forzar este tipo de controles entre distintas sentencias introducidas durante una sesión interactiva; la creación accidental de una variable entera x impediría la creación de otra variable de otro tipo que se llamara también x. Así que ABC tomo el compromiso de usar comprobación de tipos dinámicos para variables globales, y comprobación estática para variables locales. Para simplificar la implementación, al final se hacía comprobación dinámica de tipos para las variables locales también.
Así que sólo había un pequeño paso desde la implementación de ABC de comprobación de tipos hasta la de Python, simplemente descartar las comprobaciones de tipo en tiempo de compilación. Esta decisión estaba en consonancia con la filosofía Python de "ahorro de costes", ya que simplificaba la implementación sin afectar a la seguridad; los errores de tipo serían capturadas en tiempo de ejecución, antes de que pudieran producir un error en el intérprete.
En cualquier caso, no hay marcha atrás una vez que decides ir por la vía del tipado dinámico. Las operaciones de ABC se diseñaron cuidadosamente para que los tipos de los argumentos pudieran deducirse de la forma de la operación. Por ejemplo, a partir de la expresión x^y, el compilador podía deducir que las variables x e y, así como el resultado de la operación, tenían que ser cadenas de texto. En Python, este tipo de deducciones resulta, por lo general, imposible. Por ejemplo, la expresión x+y podría tratarse de una concatenación, una suma aritmética o un operador sobrecargado de un tipo definido por el usuario.
0Añadir un comentario
-
Primeras etapas del diseño y desarrollo
- Traducción de The History of Python - Early Language Design and Development
- Publicado originalmente por Guido Van Rossum, el jueves, 3 de febrero de 2009
De ABC a Python
La principal y primera influencia sobre Python fue ABC, un lenguaje diseñado a principios de los 80 por Lambert Meertens, Leo Geurts y otros en el CWI. ABC se diseñó como lenguaje de iniciación a la programación, pensado como reemplazo de BASIC, y era a la vez lenguaje y entorno para ordenadores personales. Se diseño partiendo de una análisis de las tareas asociadas a la programación, y posteriormente realizando varias interacciones que incluían varias pruebas con usuarios. Mi propio papel en el grupo ABC fue principalmente implementar el lenguaje y el entorno de edición integrado.
El uso de la indentación de Python proviene directamente de ABC, pero esta idea no tiene su origen en ABC, ya había sido promovida por Donald Knuth y era un concepto bien establecido como estilo de programación (El lenguaje Occam también lo usaba). En cualquier caso, los autores de ABC inventaron el uso de los dos puntos para marcar la cláusula anterior que marca el inicio del bloque indentado. Después de muchas pruebas de usuario sin los dos puntos, se descubrió que el significado de la indentación resultaba confuso para los que daban sus primeros pasos en la programación. Añadir los dos puntos clarificó la idea enormemente: Los dos puntos de alguna manera dirigían la atención a lo que seguía y mantenía las frases anterior y posterior relacionadas en su justa medida.
Los principales tipos de datos de Python también derivan de ABC, aunque con algunas modificaciones. Las listas de ABC eran realmente conjuntos o multiconjuntos, que se mantenían siempre ordenadas usando una implementación modificada de árboles B. Las tablas eran arrays asociativos que, de forma similar a las listas, se mantenían ordenadas por la clave. Me encontré que ninguno de los tipos de datos disponibles era adecuado para representar, por ejemplo, la secuencia de líneas leídas de un archivo, que yo preveía sería un caso habitual (En ABC, tenías que usar una tabla con los números de línea como claves, pero esto complicaba las inserciones y los borrados). Así que cambié el tipo lista para que fuera un array flexible, con operaciones de inserción y borrado, y dándole al usuario control completo en la ordenación de los elementos que componían la lista. En caso de que se necesitara realizar una ordenación de resultados, se añadió un método sort.
También cambié la implementación de las tablas ordenadas a una tabla hash. Elegí esta estructura porque pensaba que sería más rápida y fácil de implementar que los árboles B. Está última era asintóticamente óptima, en espacio y tiempo, para un gran número de operaciones, y así se había demostrado teóricamente, pero en la práctica resultaba ser difícil de implementar correctamente, debido a la complejidad de los algoritmos. Por la misma razón, el rendimiento resultada estar por debajo del óptimo para las tablas pequeñas.
No modifiqué el sistema de tuplas inmutables, por lo que las operaciones de empaquetado y desempaquetado están tomadas directamente de ABC. Como las tuplas se representan internamente como arrays, decidí añadir acceso por índices y operaciones de rodajas, igual que aquellos.
A consecuencia de añadir a las tuplas las operaciones propias de los arrays, tuve que encontrar una manera de lidiar con los casos especiales de tuplas con longitudes de 0 ó 1. Una de las reglas que tomé de ABC fue que cada tipo de datos debería ser impreso o convertido a cadena de texto de tal forma que fuera una entrada válida para el propio parser del lenguaje. De ahí, concluí que debía tener notaciones para las tuplas con uno o ningún elemento. Al mismo tiempo, me interesaba que no se perdiera la diferencia entre una tupla de un elemento y una expresión normal entre paréntesis, así que me decanté por una sintaxis fea pero pragmática, donde una coma final serviría para distinguir entre una expresión entre paréntesis y una tupla de un elemento, y "()" representaría una tupla vacía. Merece la pena hacer notar que los paréntesis no son normalmente necesarios para representar una tupla en la sintaxis de Python, excepto aquí. Pensé que representar una tupla vacía como "nada" podría enmascarar fácilmente errores auténticos.
Las cadenas de texto empezaron con una semántica muy similar a la que tenían en ABC (inmutables), pero con una notación diferente, y con índices basados en cero. Dado que ahora contaba con tres tipos diferentes de datos indexables, listas, tuplas y cadenas de texto, decidí generalizarlo como un concepto abstracto, la secuencia. Esta generalización hizo que ciertas operaciones básicas como obtener la longitud (len(s)), acceso por índices (s[i]), rodajas (s[i:j]) e iteración (for i in s) funcionaran igual en cualquier tipo derivado de la secuencia.
Los números fueron uno de los elementos donde más me aleje de ABC. Este tenía dos tipos de números en tiempo de ejecución: números exactos, que eran representados como números racionales de precisión arbitraria, y números aproximados, que se representaban como números binarios en coma flotante con rango extendido en el exponente. Los números racionales no entraban en mis perspectivas (Anécdota: En un momento dado, intenté calcular mis impuestos usando ABC. El programa, que inicialmente parecía bastante sencillo, se tomaba muchísimo tiempo para realizar incluso los cálculos más sencillos. Después de investigar un poco, descubrí que estaba haciendo cálculos aritméticos con números que tenían centenares de dígitos de precisión, redondeados a dolares y céntimos a la hora de mostrarlos). Para Python elegí un modelo más tradicional, usando enteros y números flotantes de máquina. En la implementación de Python, estos números se representaban con los tipos de C long y double respectivamente.
Presintiendo que aún así, habría un campo interesante de uso para los números exactos, añadi un nuevo tipo bignum, que llamé long. Ya disponía de una implementacion de este tipo de dato, resultado de un inacabado intento de mejorar la implementación de ABC hecho un par de años antes (La implementación original de ABC, una de mis primeras contribuciones, usaba internamente una representación decimal). Tenía sentido, por tanto, reutilizar este código en Python.
Aunque añadí este soporte para números grandes, debo enfatizar que no era mi intención que se usara este tipo de datos para todas las operaciones con enteros. Mis colegas del CWI y yo habíamos escrito y realizado pruebas de rendimiento, y sabíamos que las operaciones con enteros representan una fracción importante del tiempo total de ejecución de la mayoría de los programas. El uso más común para los enteros es, con mucho, la representación de índices para acceder a la memoria. De esa forma, planeé usar enteros sencillos para la mayoría de las operaciones, y reservar los "números grandes" para cuando se hicieran cálculos matemáticos que los demandaran, como calcular la deuda nacional de los Estados Unidos en peniques.
El problema con los números
La implementación de los números, especialmente los enteros, es una de las áreas donde cometí varios errores de diseño graves, pero donde también aprendí muchas lecciones sobre el diseño de Python.
Como Python tenía dos tipos de enteros diferentes, necesitaba una manera de distinguirlos en un programa. Mi solución fue obligar al usuario a especificar que quería usar enteros grandes, añadiendo al número la letra L como post-fijo (por ejemplo, 1234L). En este aspecto, infringí uno de los principios filosóficos de Python heredados de ABC, a saber, que el usuario no debería preocuparse por (aburridos) detalles de la implementación.
Tristemente, este fue solo un detalle insignificante de un problema mayor. Concretamente, que mi implementación de enteros y enteros largos tenían semánticas ligeramente diferentes en ciertos casos. Como el tipo int se representaba con un entero de máquina, las operaciones que excedían de 32 bits, -o cualquiera que fuera la precisión que tuvieran los tipos int en C en esa plataforma-, se truncaban silenciosamente. Además, el tipo int, que normalmente se consideran con signo, se trataban como números sin signo para las operaciones de desplazamiento o rotación de bits, así como para las conversiones desde o hacia representaciones en octal o hexadecimal. Los enteros largos, por otro lado, siempre se consideraban con signo. Así las cosas, algunas operaciones podían producir resultados diferentes, dependiendo de si el argumento utilizado fuera un entero o un entero largo. Por ejemplo, suponiendo aritmética de 32 bits, 1<<31 (1 desplazado a la izquierda 31 veces) produciría el mayor número número negativo de 32 bits, y 1<<32 produciría cero, pero 1L<<31 (1 representado como entero largo desplazado a la izquierda 31 veces) produciría un entero largo con valor 2**31, y 1L<<32 produciría 2**32.
Para resolver algunos de estos problemas hice una sencilla modificación. En vez de que las operaciones sobre enteros truncaran los resultados silenciosamente, cambia las operaciones aritméticas para que elevaran una excepción de tipo OverflowError cuando el resultado se saliera de los límites. La única excepción a esta regla fue con las operaciones de bits mencionadas antes, basándome en la presunción de que los que utilizaran estas operaciones esperarían que se comportaran como en C. Si no hubiera añadido este chequeo, los usuarios de Python sin duda habrían empezado a escribir código confiados en que podían usar la semántica de aritmética módulo 32 para enteros binarios, como hacen los programadores en C, y corregir este error después habría significado una transición mucho más dolorosa para la comunidad.
Aunque la inclusión del chequeo de desbordamiento pudiera parecer un detalle menor de la implementación, una dolorosa experiencia de captura de errores me hizo darme cuenta de que era una funcionalidad muy útil. Uno de mis primeros experimentos de programación en Python fue intentar implementar un sencillo algoritmo matemático, el cálculo de "números de Meertens", un poco de matemática recreativa inventada por Richard Bird para el 25 aniversario del principal autor de ABC en el CWI. Los primeros números de Meertens son pequeños, pero al pasar el algoritmo a código no me di cuenta de que los resultados intermedios del cálculo eran mucho mayores, y no cabían en 32 bits. Me llevó una tortuosa sesión de búsqueda de errores hasta que lo descubrí, y decidí en ese momento que zanjaría el tema comprobando todas las operaciones, por si hubiera desbordamiento, y elevando una excepción siempre que el resultado no pudiera almacenarse completo. El coste extra de la comprobación era minúsculo comparado con el coste que ya representada el crear un nuevo objeto para el resultado, una decisión que ya se había tomado.
Debo añadir que, tristemente, elevar una excepción, ¡tampoco era la solución correcta! En esa época, seguía aferrado a la siguiente regla de C: "Las operaciones con números de tipo T deben retornar un resultado de tipo T". Esta regla era también la razón de mi segundo gran error en semántica de enteros: truncar el resultado de una división de enteros, que se discutirá en otro post. En resumen, debería haber hecho que las operaciones enteras que produjeran un desbordamiento transformaran el resultado para que fuera un entero largo. Así es como funciona Python ahora, pero me llevó bastante tiempo realizar esa transición.
A pesar de los problemas con los números, surgió una idea positiva de la experiencia. Decidí que no debería haber resultados indefinidos en Python; en vez de ello, se elevarían excepciones siempre que no se pudiera devolver un resultado correctamente calculado. De esa manera, los programas en Python nunca fallarían debido a valores indefinidos circulado entre bambalinas. Esto sigue siendo un principio importante del lenguaje, tanto en el lenguaje en sí como en la librería estándar.
0Añadir un comentario
-
Veredita View no es que sea tecnología punta, es aun más extrema, es una tecnología tan avanzada que hemos tenido que inventar una nueva etiqueta para describirla: es tecnología afilada TM . Ni Google Street View puede hacerle sombra. Como podrás comprobar se trata de la solución definitiva para visualizar trayectos de punto a punto; esto lo está petando, sólo se necesita:
- Una cámara cutrona.
- Un soporte con suspensión hidráulica que neutralice dinámicamente los movimientos del recorrido y/o baches, a esto le llamaremos brazo.
- El ingrediente secreto, la música de fondo de la famosa serie Benny Hill (Yakety Sax).
- Un editor de vídeo para pasarlo a toda pastilla (Kino Video Editor).
En esta ocasión, y con motivo de la celebración del icities, mostramos el Veredita View del trayecto La Laguna -> Candelaria*:
* A la altura de Alcampo nos quedamos sin espacio en la tarjeta de SD y tuvimos que hacer una paradita para pillar otra.3Ver comentarios
-
Micosoft distribuye código Python...en 1996
- Traducción de The History of Python - Microsoft Ships Python Code... in 1996
- Publicado originalmente por Greg Stein, el miércoles, 28 de enero de 2009
¡Gracias a Guido por permitirme compartir mi propia historia de Python!
Me reservaré mi propios inicios en Python para otro artículo, pero el resultado final fue la incorporación de Python en una empresa que varias personas y yo fundamos en 1991. Trabajábamos en un enorme sistema cliente/servidor que gestionaría el comercio electrónico entre empresas y consumidores. Protocolos propietarios construidos sobre TCP y que funcionaban con las antiguas redes X.25, y esas cosas. Vieja escuela.
En 1995 nos dimos cuenta de que, al contrario de lo que pensábamos, la mayoría de los consumidores estaban en Internet, y que necesitábamos un sistema para que nuestros clientes (los vendedores) llegaran a este mercado. Se me encargó la tarea de planear nuestra aproximación, y elegí Python como herramienta de prototipado.
Nuestro primer problema era migrar a una solución basada enteramente en el navegador web. El cliente específico que habíamos desarrollado no era viable, por lo que tuvimos que desarrollar de nuevo toda la interfaz de compra del consumidor, y construir una infraestructura web que la soportara. En ese momento, esto significaba escribir scripts CGI para servidores Apache o Netscape. Conectábamos con nuestro sistema de gestión de pedidos preexistente usando CGI, para procesar las ordenes de compra, gestionar el carrito de productos y para obtener información acerca de los productos. Los scripts CGI producían Html puro y duro, ¡No había AJAX en 1995!
Esta solución estaba lejos de ser ideal, debido a la sobrecarga que significaba para el sistema el crear un nuevo proceso para cada petición. La respuesta del servidor era pobre. Entonces, en diciembre de 1995, mientras asistía al taller de Python en la ciudad de Washington, me encontré con unos módulos para Apache y Netscape (escritos por Digital Creations, más conocidos por su producto Zope) que corrían de forma persistente. Los módulos se comunicaban con el servidor mediante un sistema RPC llamado ILU. Una vez montado este sistema, la sobrecarga de la creación de los procesos desaparecía y la experiencia del usuario era muchísimo más satisfactoria. Empezamos a convertir el prototipo en código real. Cuanto más avanzábamos, mejor pinta tenía y más gente se sumaba al proyecto. El desarrollo se disparó espectacularmente pasados al par de meses (¡Gracias, Python!).
En enero de 1996, Microsoft tocó en nuestra puerta. Sus esfuerzos internos para crear un sistema de comercio electrónico estaban estancados y necesitaban gente que conociera la industria (Nosotros llevábamos por entonces varios años haciendo comercio electrónico) y también que fueran ágiles. Seguimos desarrollando el sistema a la vez que manteníamos las negociaciones, y finalmente la adquisición se llevó a cabo en junio de 1996.
Una vez que desembarcamos en Microsoft con nuestro código Python, tuvimos que encontrar una manera de incluir nuestro producto en Windows NT. El equipo al que nos unimos tenía mucha experiencia en Windows, y construyeron un plugin para IIS que se comunicaba usando named pipes con el servidor principal, que eran servicios NT con el código Python embebido. Después de una carrera de fondo que empezó en julio, sacamos Microsoft Merchat Server 1.0 en octubre de 1996.
Y efectivamente, si mirabas con atención, un poco escondido, había un interprete de Python, algunas extensiones en forma de DLL, y un montón de archivos .pyc. Microsoft, ciertamente, no lo anunció de manera alguna, pero estaba allí, y lo podías ver, si sabías donde mirar.
0Añadir un comentario
-
Historia personal - Segunda parte, el CNRI y más allá
- Traducción de The History of Python - Personal History - part 2, CNRI and beyond
- Publicado originalmente por Guido Van Rossum, el martes, 27 de enero de 2009
El taller de Python (véase el post anterior) fructificó en una oferta para investigar sobre agentes móviles para el CNRI (Corporation for National Research Initiatives). El CNRI es una organización sin ánimo de lucro ubicado en Reston, Virginia. Me incorporé en abril de 1995. El director del CNRI, Bob Kahn, fue el primero en señalarme lo mucho que tenían en común Python y Lisp, a pesar de ser completamente diferentes a un nivel superficial o sintáctico. El trabajo en Python fue financiado indirectamente por una beca de DARPA para la investigación en agentes móviles. Aunque DARPA apoyaba varios proyectos que usaban Python, no existía ninguna ayuda directa para el desarrollo de lenguajes en si.
En el CNRI dirigí y ayude a contratar a un pequeño equipo de desarrolladores que implementaron un agente móvil usando sólo Python. El equipo inicial contaba con Roger Masse y Barry Warshaw, que cayeron presa del mordisco de la serpiente mientras trabajaban allí. Además, contratamos a miembros de la comunidad como Ken Manheimer y Fred Drake. Jeremy Hilton, un graduado del MIT que fue contratado inicialmente para trabajar en recuperación de textos, acabó uniéndose al equipo, también. El equipo fue gestionado inicialmente por Ted Strollo y luego por Al Vezza.
Con la ayuda de este equipo pudimos crear y mantener infraestructura adicional para la comunidad de Python, como el sitio web python.org, un servidor de cvs y las listas de correo de diferentes Grupos de Interés Especiales de Python. Las versiones 1.3 hasta 1.6 fueron liberadas mientras trabajaba aquí. La versión 1.5.2 fue la más popular y la más estable durante muchos años.
Aquí nació también el software GNU Mailman: Originalmente usábamos una utilidad escrita en Perl llamada Majordomo, pero Ken Manheimer la encontraba inmantenible y buscó una solución en Python. Encontró algo parecido escrito en Python por John Viega y asumió su mantenimiento. Cuando Ken dejó el CNRI, para irse a Digital Creations, Barry Warshaw continuó con su trabajo, y convenció a la Free Software Foundation para que adoptara Mailman como su gestor de listas de correo oficial. Posteriormente Barry lo licenció bajo la GPL (GNU Public License).
Los talleres de Python continuaron, al principio dos veces al año, pero debido a su crecimiento y al aumento de logística necesarios rápidamente se convirtieron en eventos anuales. Al principio se organizaban allí donde alguien se ofreciese a albergarlos, como en el NIST (el primero), el USGS (segundo y tercero) y el LLNL (el cuarto y el principio de una serie anual). Finalmente el CNRI asumió la organización, y más tarde (Junto con las conferencias del IEFT y el WWW) se organizó mediante una organización derivada comercial, Fortec. La asistencia se elevó rápidamente a varios centenares. Cuando Fortec se disolvió, poco después de que yo dejara el CNRI, la Conferencia Internacional de Python fue alojada en las conferencias de Código Abierto de O'Reilly (OSCON), y al mismo tiempo la Python Software Foundation (se hablará de ella más adelante) comenzó una nueva serie de conferencias de base llamadas Pycon.
También creamos la primera (e informal) organización sobre Python en el CNRI. Respondiendo a los esfuerzos de Mike McLay y Paul Everitt de crear una "Fundación Python", pronto nos encontramos atrapados en las arenas movedizas legales, por lo que Bob Kahn propuso crear la Python Software Activity, que no sería una entidad legalmente independiente, sino un grupo de personas amparadas bajo el estatus legal (sin ánimo de lucro) del CNRI. El PSA tuvo éxito en encauzar a un gran número de usuarios comprometidos con Python, pero su falta de independencia limitaba su efectividad.
El CNRI también usó los fondos de DARPA para financiar el desarrollo de JPython (más tarde abreviado Jython), una implementación de Python en Java. Jim Hugunin comenzó el proyecto mientras acababa su graduado en el MIT, y luego convenció al CNRI para que le contratara para terminarlo (O quizá fuese al revés, y el CNRI convenciera a Jim --Ocurrió durante mis vacaciones). Cuando Jim dejó el CNRI apenas dos años después, para incorporarse al proyecto AspectJ en el Xerox PARC, Jython fue continuado por Barry Warshaw. Mucho más tarde, Jim sería también al creador de IronPython, la versión de Python para la plataforma .NET de Microsoft. Jim también escribió la primera versión de Numeric Python.
Varios otros proyectos del CNRI comenzaron a usar Python. Varios desarrolladores claves del núcleo de Python surgieron de estos proyectos, especialmente Andrew Kuchling, Neil Schemenauer y Greg Ward, que trabajaban en el proyecto MEMS Exchange (Andrew había contribuido antes incluso de unirse al CNRI; su primer proyecto de éxito fue el Python Cryptography Toolkit, una librería adicional que implementa diferentes algoritmos criptográficos, disponible para los usuarios de Python).
Basándose en los logros obtenidos con Python, en CNRI intentó obtener una vía de financiación que permitiera el desarrollo del lenguaje de forma más directa de lo que permitían las becas de DARPA. Se creo así el Python Consortium, basado en el mismo modelo que el X consortium, con una cuota de entrada mínima de 20.000$. En cualquier caso, aparte de un grupo en Hewlett-Packard, no se consiguió demasiado apoyo, y el consorcio acaba muriendo de anemia. Otro intento de conseguir financiación fue el CP4E (Computer Programming For Everybody), que recibió algunos fondos del DARPA. En cualquier caso, pronto se puso de relieve que los fondos obtenidos no eran suficientes para todo el equipo. Era una situación que no me gustaba, por lo que empecé a considerar otras opciones.
Finalmente, a principios del 2000, la burbuja de las punto com, que todavía no había estallado, me convenció a mi y a otros tres miembros del equipo Python del CNRI (Barry Warsaw, Jeremy Hylton y Fred Drake) para unirnos a BeOpen.com, una startup de California que estaba reclutando desarrolladores de código abierto. También se unió Tim Peters, un contribuidor clave de la comunidad Python.
Anticipando la transición a BeOpen.com, surgió la difícil pregunta acerca de la futura propiedad de Python. El CNRI insistió en cambiar la licencia, y que se usara la nueva para liberar la versión 1.6. La antigua licencia usada desde que estaba en el CWI era una variación de la licencia del MIT. Las versiones liberadas en el CNRI usaban básicamente la misma, con una ligera modificación que consistía en el añadido de una cláusula de exención de responsabilidades. La licencia de la versión 1.6, por el contrario, era un largo texto de prosa legal manufacturado por los abogados del CNRI.
Mantuvimos largas y agotadoras discusiones con Richard Stallman y Eben Moglen, de la Free Software Foundation, sobre algunas partes de la nueva licencia. Estaban preocupados por si resultara ser incompatible con la GPL, lo que comprometería la viabilidad de GNU MailMan, que por entonces se había convertido en una herramienta esencial para la FSF. Con la ayuda de Eric Raymond, se hicieron los cambios necesarios para que la nueva licencia fuera aceptable tanto para el CNRI como para la FSF, pero el texto resultante era sin duda difícil de entender. Lo único bueno que puedo decir es que finalmente (y de nuevo gracias a Eric Raymond) se obtuvo el sello de la Open Source Initiative, que garantizaba que era un genuino producto de código abierto. Solo se hicieron con posterioridad pequeñas modificaciones, para reflejar los sucesivos cambios de propiedad, primero a favor de BeOpen.com y luego de la Python Software Foundation, pero en esencia el trabajo de los abogados del CNRI sigue allí.
Como tantas otras startups de ese periodo, el plan de negocios de BeOpen.com falló de forma espectacular. Dejó a su paso una deuda considerable, muchas dudas razonables acerca del papel jugado por algunos de los ejecutivos de la firma, y un montón de desarrolladores desilusionados, entre los cuales estaba mi propio equipo.
Afortunadamente nuestro equipo, conocido entonces como PythonLabs, estaba bastante bien considerado y fue contratado por Digital Creations, una de las primeras empresas en usar Python (Ken Manheiner nos había precedido allí por unos cuantos años). Digital Creations cambió su nombre a Zope Corporation, basándose en su producto de código abierto de más éxito, el gestor de contenidos Zope. Paul Everitt y Rob Page, los fundadores, habían asistido a los primeros talleres en el NIST en 1994, al igual que su CTO, Jim Fulton.
La historia podría haber sido muy diferente; además de Digital Creations, también estábamos considerando ofertas de VA Linux y ActiveState. VA Linux era una estrella en alza en la bolsa, pero con el tiempo el precio de sus acciones (Que habían convertido a Eric Raymond en multimillonario, al menos sobre el papel) se colapsó dramáticamente. Mirando hacia atrás, creo que ActiveState no habría sido una mala opción, a pesar de la fama de controvertido de su fundador, Dick Hardt, pero estaba ubicada en Canadá.
En el 2001 se creo la Python Software Foundation, una organización sin ánimo de lucro, cuyos miembros iniciales eran los principales colaboradores en el desarrollo de Python en ese momento. Eric Raymond fue uno de los miembros fundadores. Todavía tengo más que escribir sobre este periodo, pero será en otro momento.
0Añadir un comentario
-
El lunes, 13 de abril, asistiremos a un evento imprescindible para los interesados en la innovación y/o el turismo. En Innotur09 se nos presentarán las conclusiones obtenidas de un largo estudio sobre los dos temas , realizado por la Fundación Empresa Universidad de La Laguna y la Fundación Universitaria de Las Palmas. Pero será también una oportunidad para ver a mucha gente interesante, que solo nos vemos en los saraos estos (y en algunos Blogs & Gofio, claro). De las ponencias y presentaciones, aparte de las conclusiones ya mencionadas, las que más me llaman la atención son las de Jimmy Pons, gurú de la web/Travel 2.0 y las de la gente de minube.com, para mi una de las empresas más simpáticas del panorama patrio. El resto de las ponencias, sin embargo, también parece muy atractivo; como se puede comprobar si ven el programa de las jornadas Innotur09.
Donde: En el Centro de Congresos del Puerto de la Cruz, en el Parque Taoro, 22.
Cuando: El lunes, 13 de abril de 2009, a las 17:00 horas (Las acreditaciones empiezan a a las 16:30).
Más información: La página web del evento Innotur 09
PD: Y el viernes, 24, en el iCities, ¡la cosa no para!0Añadir un comentario
-
Ayer, llevados por la necesidad (Y también un poco por la necedad), anunciabamos el i=√-1 Blogs & Gofio retroconvocado. Hoy, casi por las mismas razones (Sobre todo la segunda), tenemos que anunciar la convocatoria de un Pre Blogs & Gofio, un tanto precipitado, eso si, porque será mañana, martes, 7 de abril de 2009, y hablaremos de algunas cosas sorprendentes que pueden pasar, o no, en el próximo Blogs & gofio, el de verdad, el que convoca Rafa desde su Blog La gaveta de la derecha - Blogs&Gofio XXI en el iCities’09 (¡Chacho! ¡Qué todavía no te has apuntado! Vete corriendo, alístate y elige pescadito, pulpo o calamares).
¿Donde?
En el Viana, pero en el nuevo, ¿Eh? El que está por San Benito, Calle Juana La Blanca 31. Es más fácil aparcar por aquí, sobre todo ahora que están los No-Creyentes-En-Doraemon (Que su Azulidad les perdone) con sus cositas.¿Cuándo?
Mañana, martes, 7a las jochoymedia, hombre, ya lo dije antes.¿Cómo?
Esta convocatoria tiene carácter clandestino, es top-secret, no se puede contar, difundir, replicar ni susurrar, en caso de incumplimiento del secretismo se sancionará bajo una pena de muerte por fuegoyheavy. Cualquiera puede asistir, sólo hay que presentarse intentando pasar desapercibido, esto es, rollo gabardina, gafas de sol, manos en los bolsillos y silbido átono e innecesario.
0Añadir un comentario
-
Retroconvocatoria de Blogs and Gofio
Ayer coincidimos en la misma mesa, en el mismo bar y en el mismo momento una caterva de individuos: La Becaria (Doraemon por el mundo), Tooenchumbao (El Blog de Tooemchumbao), Mapoto (Crucemos los dedos), Ex-Seminarista Ye-yé (El Infierno es aquí), Vespinoza (Malditas Mentiras) y su seguro servidor, El Ornitorrinco (El Ornitorrinco Enmascarado)
¿Una coincidencia? Sólo las mentes más ingenuas podrían pensar eso. Una casualidad así, a este nivel, significaría una ruptura catastrófica del continuo espacio-bares-tiempo, una violación de las leyes de la termodinámica, una ruptura de la causalidad. No, debemos rechazar y rechazamos de pleno esa hipótesis. No fue casualidad, no pudo serlo.
Pero lo que resulta innegable es que sobre esa mesa, en ese momento, se produjo un fenómeno que muchos físicos y cosmólogos habían predicho, aunque no se había observado hasta ahora en la naturaleza: La creación espontánea de un Blogs and Gofio. Los datos son indiscutibles; en aquella mesa había más bloggers que en muchos blogs & gofio oficiales.
Pero claro, existe un problema crucial. ¿Y la convocatoria? Sin convocatoria no hay Blogs & Gofio. Pero hubo un Blog & Gofio. ¿Cómo escapar de este dilema circular? ¿Como romper la cadena causal que nos tiene atrapados?
Fácil.
Es decir, fácil si has leído los suficientes cómics, has vista las suficientes películas, y has conseguido el nivel de ensuciado mental [1] que te permite hablar de tú a tú con Sheldon Cooper.
Una clásica Wells de 1895, como nuevaLa única opción posible es la retrocontinuidad. Debemos convocar hoy, pero con fecha de ayer. Lamentablemente, esto limita la asistencia a aquellos que cumplan alguna de las siguiente condiciones:
- Tener acceso a una Tardis, o ser compañero de alguien que tenga acceso a una Tardis
- Disponer de un Delorean modificado, con condensador de fluzo activo y revisado ITV 2009
- Ser un Terminator Skynet modelo T-1000 o superior
- Acceso a una Maquina del Tiempo H.G. Wells original, en buenas condiciones de uso
- Acceso a una Maquina del Tiempo Von Doom/Richards, con o sin efecto Kirby
- Ser la chica del anuncio de Neutrex Futura (Aportación de Mapoto)
- El Supermán Pre-crisis, en su calidad de miembro de la Legión de Superheroes (Aportación de Mapoto)
- Tener capacidades extrasensoriales y precognitivas. En ese caso ¿Ya lo sabias desde anteayer, no?
Lamentamos esta discriminación, pero no vemos otra posibilidad, y la misma existencia del Universo peligra. Así que por la presente se convoca la primera (i) retroconvocatoria de Blogs y Gofio, a celebrar el Jueves, 2 de abril de 2009, en la cervecería Tropical, a las 20:30.
[1] Ensuciado mental: Lo contrario de lavado mental.
8Ver comentarios
Añadir un comentario