Historia personal - parte 1, CWI

El desarrollo de Python empezó en un instituto de investigación en Amsterdam llamado CWI, el cual es un acrónimo en holandés que en español significa Centro de Matemáticas y Ciencias de la computación. CWI es un lugar interesante; fundado por el Departamento de Educación del gobierno y otros fondos para investigación, guía investigaciones de nivel académico en ciencias de la computación y matemáticas. En todo momento está lleno de estudiantes de doctorado paseando y los más viejos profesionales deben aún recordar su nombre original, el Centro Matemático. Bajo este nombre, es tal vez más famoso por la invención de Algol 68.

Empecé a trabajar en CWI al final de 1982, recién salido de la universidad, como programador en el grupo de desarrollo de ABC liderado por Lambert Meertens y Steven Pemberton. Luego de 4 o 5 años, el proyecto ABC fue interrumpido debido a la obvia falta de éxito y me trasladé al grupo Amoeba liderado por Sape Mullender. Amoeba era un sistema operativo distribuido basado en micro-kernel desarrollado en forma conjunta por CWI y la Vrije Universiteit of Amsterdam, bajo la dirección de Andrew Tanenbaum. En 1991, Sape dejó CWI para dar clases en la University of Twente y terminé en otro grupo recientemente formado en CWI sobre multimedia liderado por Dick Bulterman.

Python es un producto directo de mi experiencia en CWI. Como explico más adelante, ABC me dio la inspiración clave para Python, Amoeba la motivación inmediata, y el grupo multimedia fomentó su crecimiento. Sin embargo, hasta donde sé, ningún fondo de CWI fue alguna vez destinado oficialmente para su desarrollo. En cambio, sólo evolucionó como una herramienta importante para usar en los grupos Amoeba y de multimedia.

Mi motivación original pare crear Python fue la necesidad que percibí por un lenguaje de alto nivel en el proyecto Amoeba. Me dí cuenta de que el desarrollo de utilidades para administración de sistemas en C llevaría mucho tiempo. Más aún, hacer esto en el shell Bourne funcionaría por una variedad de razones. La más importante fue que al ser Amoeba un sistema micro-kernel distribuido con un diseño radicalmente nuevo, sus operaciones primitivas eran diferentes (y de granularidad fina) de las primitivas tradicionales disponibles en el shell Bourne. Existía la necesidad de un nuevo lenguaje que "una la brecha entre C y el shell". Por mucho tiempo, este fue el principal slogan de Python.

En este punto tal vez se pregunte "¿por qué no portar un lenguaje existente?". En mi forma de verlo, no había muchos lenguajes apropiados en esos días. Estaba familiarizado con Perl 3, pero estaba más atado a Unix que el shell Bourne. Tampoco me gustaba la sintaxis de Perl --mi gusto en la sintaxis de los lenguajes de programación fue fuertemente influenciado por lenguajes como Algol 60, Pascal, Algol 68 (a todos los había aprendido mucho antes) y, por último pero no el peor, ABC, en el cual gasté cuatro años de mi vida. Así que decidí diseñar un lenguaje por mi cuenta que tomaría prestado todo lo que me gustaba de ABC a la vez que arreglaba todos sus problemas (como los percibía).

¡El primer problema que decidí arreglar era el nombre! Sucedió que el equipo de desarrollo de ABC tenía algunos problemas en elegir un nombre para su lenguaje. El nombre original del lenguaje, B, tuvo que ser abandonado porque se confundía con otro lenguaje llamado B, que era más viejo y más conocido. De cualquier modo, B era solo un título de trabajo (el chiste era que B era el nombre de la variable que contenía el nombre del lenguaje, de ahí la itálica). El equipo tuvo un concurso público para obtener un nuevo nombre, pero ninguna de las propuestas fue apropiada, y al final el backup interno prevaleció. Con el nombre se quería expresar la idea de que el lenguaje hacía que la programación sea "tan simple como el ABC", pero a mi nunca me convenció mucho.

Así que, en lugar de sobre analizar el problema del nombre, decidí hacer lo contrario. Elegí el primer nombre que me vino a la mente, que resultó ser Monty Python’s Flying Circus, uno de mis grupos cómicos preferidos. La referencia parece bastante irrelevante para lo que era esencialmente un proyecto innovador pero solitario. La palabra "Python" era pegadiza, te ponía un poco los pelos de punta, y al mismo tiempo encajaba en la tradición de ponerle a los lenguajes nombres de personas famosas, como Pascal, Ada y Eiffel. Puede que el equipo de The Monty Python no sea famoso por sus avances en ciencia o tecnología, pero son ciertamente un favorito de los geeks. También encajaba en la tradición del grupo Amoeba de CWI de ponerle a los programas el nombre de shows televisivos.

Por muchos años resistí la tentación de asociar el lenguaje con serpientes. Finalmente me rendí cuando O'Reilly quizo poner una serpiente en la tapa del primer libro de Python "Programming Python". Era una tradición de O'Reilly usar fotos de animales, y si tenía que ser un animal, que sea una serpiente.

Con el asunto del nombre resuelto, empecé a trabajar en Python a finales de diciembre de 1989, y tuve una versión funcionando en los primeros meses de 1990. No tomé notas, pero recuerdo vivamente que la primer pieza de código que escribí de la implementación de Python era un LL(1) parser generator simple que llamé "pgen". Este parser generator es aún parte de los fuentes de Python y probablemente lo menos cambiado de todo el código. Esta versión temprana de Python fue usada por algunas personas en CWI, mayormente, pero no en forma exclusiva en el grupo Amoeba durante 1990. Los desarrolladores clave, demás de mi, eran mis compañeros de oficina, los programadores Sjoerd Mullender (el hermano menor de Sape) y Jack Jansen (quien fue uno de los desarrolladores líderes de la versión para Macintosh por muchos años, luego de dejar CWI).

El 20 de febrero de 1991 publiqué por primera vez Python para el mundo en el grupo de noticias alt.sources (como 21 partes codificadas que tenían que ser juntadas y decodificadas para formar el archivo tar comprimido). Esta versión fue etiquetada 0.9.0 y publicada bajo una licencia que era prácticamente una copia textual de la licencia MIT usada por el proyecto X11 en ese entonces, poniendo “Stichting Mathematisch Centrum”, la organización padre de CWI, como la entidad responsable legal. Así que, como casi todo lo que he escrito, Python era open source antes de que el término sea inventado por Eric Raymond y Bruce Perens a finales de 1997.

Enseguida hubo mucha retroalimentación y con este apoyo mantuve un firme flujo de publicaciones durante algunos años. Empecé a usar CVS para seguir los cambios y para facilitar compartir la responsabilidad de codificar con Sjoerd y Jack (coincidentemente, CVS fue desarrollado originalmente como un set de shell scripts por Dick Grune, quien era uno de los miembros originales del equipo de desarrollo de ABC). Escribí una FAQ, que era regularmente publicada en algunos grupos de noticias, como era costumbre para las FAQs en aquellos días anteriores a la web. Empecé una lista de correos, en marzo de 1993 se creó el grupo de noticias comp.lang.python con mi apoyo pero sin estar directamente involucrado. El grupo de noticias y la lista de correos fueron unidos mediante un gateway bidireccional que aún existe, aunque hoy está implementado con mailman (el gestor de listas de correos líder, escrito en Python).

En el veranode 1994, en el grupo de noticias apareció un hilo titulado "¿si a Guido lo atropella un colectivo?" sobre la dependencia de la creciente comunidad de Python en mis contribuciones personales. Culminó con una invitación que me hizo Michael McLay para pasar dos meses como investigador invitado en el NIST, el Instituto Nacional de Estándares y Tecnologías de los Estados Unidos, antes el Bureau Nacional de Estándares, en Gaithersburg, Maryland. Michael tenía varios "clientes" del NIST interesados en usar Python para una variedad de proyectos relacionados con estándares y el presupuesto para mi estancia allí nació de la necesidad de ayudarlos a mejorar sus habilidades con Python, así como posiblemente adaptar Python a sus necesidades.

El primer workshop de Python se llevó a cabo mientras estuve allí en noviembre de 1994, con el programador del NIST, Ken Manheimer, dándome un importante apoyo. De los aproximadamente 20 asistentes, alrededor de la mitad son aún participantes activos de la comunidad de Python y algunos se volvieron líderes principales de proyectos open sources (Jim Fulton de Zope y Barry Warsaw de GNU mailman). Con el apoyo del NIST también di una charla para 400 personas en la conferencia Usenix Little Languages en Santa Fe, organizada por Tom Christiansen, un defensor de Perl de mente abierta quien me presentó al creador de Perl, Larry Wall, y al author de Tcl/Tk, John Ousterhout.

En la próxima entrega: cómo conseguí un trabajo en los Estados Unidos...

Traducido por Juan José Conti.

Revisado por César Portela.

Si encontrás errores en esta traducción, por favor reportalos en un comentario y los corregiremos a la brevedad.

Todas las traducciones de esta serie pueden encontrarse en La historia de Python.

Cronología breve de Python

El desarrollo de Python y el de otros lenguajes de programación dinámicos (y open source) como Tcl, Perl y (más tarde) Ruby se llevaron a cabo al mismo tiempo; estos se desarrollaban activamente a la vez que iban ganando popularidad. Para poner a Python en su propia perspectiva histórica, la siguiente lista muestra su historia de releases (publicaciones). Las fechas más tempranas son aproximadas, ya que no llevaba un registros de todos los eventos:

Añadí enlaces a los releases que aún se anuncian en python.org en estos momentos. Notar que muchos releases fueron seguidos de varios micro releases, por ejemplo 2.0.1; no me molesté en incluirlos en la tabla porque se habría vuelto muy larga. El código fuente empaquetado de cada viejo release está disponible en http://www.python.org/ftp/python/src/. Varios releases antiguos en forma binaria y otros artefactos históricos también pueden encontrarse subiendo un nivel desde allí.

Traducido por Juan José Conti.

Revisado por César Portela.

Si encontrás errores en esta traducción, por favor reportalos en un comentario y los corregiremos a la brevedad.

Todas las traducciones de esta serie pueden encontrarse en La historia de Python.

Filosofía de Diseño de Python

Los próximos artículos se sumergirán en los detalles internos de la historia de Python. Sin embargo, antes de hacer eso, me gustaría detallar las guías filosóficas que me ayudaron a tomar decisiones mientras diseñaba e implementaba Python.

Ante todo, Python fue originalmente concebido como un proyecto de una sola persona; no había presupuesto oficial, y quería resultados rápidos, en parte para poder convencer a los gerentes de apoyar el proyecto (en el que estaba teniendo bastante éxito). Esto llevó a un número de reglas para ahorrar tiempo:

• Tomar ideas prestadas de otros lugares siempre que tuviera sentido.
• "Las cosas deben ser tan simples como sea posible, pero no más simples." (Einstein)
• Haz una cosa bien (la "filosofía de Unix").
• No preocuparse mucho sobre la performance; planea optimizar luego, cuando sea necesario.
• No pelear con el entorno y seguir la corriente.
• No intentar la perfección porque "suficientemente bueno" es a menudo eso.
• (Corolario) Está bien tomar atajos a veces, especialmente si se puede hacer bien luego.

Otros principios no fueron pensados para ahorrar tiempo. A veces era justamente lo contrario:

• La implementación de Python no debe estar atada a una plataforma en particular. Está bien si algunas funcionalidades no están siempre disponibles, pero el núcleo debe correr en todo lugar.
• No molestar a los usuarios con detalles de los que la máquina se puede encargar (no siempre seguí esta regla y algunas de las desastrosas consecuencias se describen en las siguientes secciones).
• Soportar y animar a que el código de los usuarios sea independiente de la plataforma, pero no evitar el acceso a las capacidades o propiedades de la plataforma (esto contrasta bruscamente con Java).
• Un sistema complejo y grande debe poderse extender en muchos niveles. Esto maximiza las oportunidades para los usuarios, sofisticados o no, de ayudarse a sí mismos.
• Los errores no deben ser fatales. Esto significa que el código de los usuarios debe ser capaz de recuperarse de condiciones de error mientras que la máquina virtual siga funcionando.
• Al mismo tiempo, los errores no deben pasar inadvertidos (estos dos últimos ítems llevan naturalmente a la decisión de usar excepciones en la implementación).
• No se debe permitir que un error en el código Python del usuario lleve al intérprete de Python a un comportamiento no definido; un fallo de segmento (core dump) no es nunca culpa del usuario.

Finalmente, tengo varias ideas sobre el diseño de buenos lenguajes de programación, que el grupo de desarrollo de ABC marcó en mí; en él tuve mi primera experiencia real con el diseño e implementación de lenguajes. Estas ideas son las más difíciles de poner en palabras, ya que la mayoría giran en torno a conceptos subjetivos como elegancia, simplicidad y legibilidad.

A pesar de que más adelante voy a tratar más sobre la influencia de ABC en Python, me gustaría mencionar especialmente una regla de legibilidad: los caracteres de puntuación deben ser usados en forma conservadora, de forma alineada con el uso que se les da en Inglés o álgebra universitaria. Se hacen excepciones cuando una notación particular es una tradición antigua en los lenguajes de programación, como "x*y" para multiplicar, "a[i]" para acceder al elemento de un array o "x.foo" para seleccionar un atributo, pero Python no usa "$" para indicar variables, ni "!" para indicar operaciones con efectos secundarios.

Tim Peters, un antiguo usuario de Python quien eventualmente se convirtió en su más prolífero y tenaz desarrollador del núcleo, intentó capturar mis principios de diseño tácitos en lo que llamó el "Zen de Python". Lo cito aquí enteramente:

• Hermoso es mejor que feo.
• Explícito es mejor que implícito.
• Simple es mejor que complejo.
• Complejo es mejor que complicado.
• Plano es mejor que anidado.
• Ralo es mejor que denso.
• La legibilidad importa.
• Los casos especiales no son tan especiales como para romper las reglas.
• Aunque lo práctico vence a lo puritano.
• Los errores nunca deben pasar desapercibidos.
• A menos que sean explícitamente silenciados.
• Ante la ambigüedad, rechaza la tentación de adivinar.
• Debe haber una forma (y preferentemente sólo una forma) obvia de hacerlo.
• Aunque esa forma no sea obvia al principio a menos que seas Holandés.
• Ahora es mejor que nunca.
• Aunque nunca es a menudo mejor que ya.
• Si la implementación es difícil de explicar, es una mala idea.
• Si la implementación es fácil de explicar, puede ser una buena idea.
• Los espacios de nombre son geniales; hagamos más de ellos!

A pesar de que mi experiencia en el grupo de desarrollo de ABC influenció en gran medida a Python, tenían algunos principios de diseño que eran radicalmente diferentes a los de Python. De muchas maneras, Python nace deliberadamente de estos:

• El grupo de desarrollo de ABC se esforzaba en alcanzar la perfección. Por ejemplo, usaban algoritmos de estructuras de datos arbóreas que se había probado eran óptimos para casi infinitas colecciones (pero no eran tan geniales para colecciones pequeñas).
• Querían aislar al usuario, tanto como sea posible, del "enorme y malvado mundo de las computadoras" que había ahí afuera. No solo no debía haber un límite en el rango de números, el largo de las cadenas de texto, o el tamaño de las colecciones (aparte del total de memoria disponible), sino que los usuarios tampoco tendrían que ocuparse de discos, otros programas o guardar archivos. ABC debía ser la única herramienta que podrían necesitar. Este deseo también causó que el grupo de desarrollo de ABC cree un entorno de edición totalmente integrado, único para ABC (por supuesto, había una posibilidad de escapar del entorno de ABC, pero fue una idea de último momento y no era accesible directamente desde el lenguaje).
• Asumieron que los usuarios no tendrían experiencia previa con computadoras (o estarían deseando olvidarla). Así, se introdujo terminología alternativa considerada más amigable para los novatos que términos estándares de programación. Por ejemplo, los procedimientos se llamaban "how-tos" y las variables "locations".
• El grupo de desarrollo de ABC diseñó ABC sin un camino evolutivo en mente y sin esperar la participación de los usuarios en el diseño del lenguaje. ABC fue creado como un sistema cerrado, tan impecable como sus diseñadores podían hacerlo. No se alentaba a los usuarios a mirar que pasaba dentro. Aunque se habló sobre abrir partes de la implementación a usuarios avanzados durante las últimas etapas del proyecto, esto nunca se concretó.

En muchas formas, la filosofía de diseño que usé cuando diseñaba Python es probablemente una de las principales razones de su éxito final. En lugar de intentar alcanzar la perfección, los primeros usuarios vieron que Python funcionaba "suficientemente bien" para sus propósitos. Al crecer la base de usuarios, se incorporaron gradualmente sugerencias para mejorar el lenguaje. Como veremos en las futuras secciones, muchas de estas mejoras necesitaron cambios sustanciales y la reimplementación del núcleo del lenguaje. Incluso hoy, Python continua evolucionando.

Traducido por Juan José Conti.

Revisado por César Portela.

Si encontrás errores en esta traducción, por favor reportalos en un comentario y los corregiremos a la brevedad.

Todas las traducciones de esta serie pueden encontrarse en La historia de Python.

Introducción

Python es en la actualidad uno de los lenguajes de programación dinámicos más populares, junto con Perl, Tcl, PHP y ahora Ruby. A pesar de ser a menudo visto como un lenguaje de "scripting", es en realidad un lenguaje de programación de propósito general como Lisp o Smalltalk. Hoy, Python es usado para todo, desde scripts que luego se tiran hasta servidores web de alta escalabilidad que proveen servicio ininterrumpido 24x7. Permite crear interfaces de usuario, programar con bases de datos, realizar programación web tanto del lado del servidor como del cliente y testear aplicaciones. Es usado por científicos que escriben aplicaciones para las más rápidas supercomputadoras del mundo y por niños que están aprendiendo a programar.

En este blog, voy a concentrarme en la historia de Python. En particular, cómo Python fue desarrollado, las principales influencias en su diseño, errores cometidos, lecciones aprendidas y futuras direcciones para el lenguaje.

Reconocimiento: Estoy en deuda con Dave Beazley por muchas de las mejores oraciones en este blog. (Para saber más sobre los orígenes de este blog, vea mi otro blog.)

Un repaso rápido a Python

Cuando uno se encuentra con Python por primera vez, a menudo se sorprende de que el código Python se vea, por lo menos superficialmente, similar a código escrito en otros lenguajes de programación convencionales como C o Pascal. Esto no es un accidente; la sintaxis de Python toma mucho prestado de C. Por ejemplo, muchas de las palabras claves de Python (if, else, while, for, etc.) son las mismas que en C, los identificadores en Python tienen las mismas reglas que los de C, y muchos de los operadores estándares tienen el mismo significado que en C. Por supuesto, Python no es C y una de las principales áreas dónde difiere es que en lugar de usar llaves para agrupar sentencias, usa indentación. Por ejemplo, en lugar de escribir sentencias en C como:

if (a < B) {

    max = b:

} else {

    max = a;

}

Python simplemente se deshace de todas las llaves (y de los punto y coma finales) y usa la siguiente estructura

if a < b:

    max = b

else:

    max = a

Otra área importante en la que Python se diferencia de los lenguajes del estilo de C es en su uso de tipado dinámico. En C, las variables siempre deben ser declaradas explícitamente y se les debe dar un tipo específico como int o double. Esta información es luego usada para hacer verificaciones estáticas en tiempo de compilación del programa y para reservar memoria para almacenar el valor de las variables. En Python, las variables son simplemente nombres que hacen referencia a objetos. No se necesita declarar las variables antes de que sean asignadas e incluso pueden cambiar de tipo en el medio de un programa. Como otros lenguajes de programación dinámicos, todas las verificaciones de tipo se hacen en tiempo de ejecución por un intérprete en lugar de en un paso de compilación separado.

Los tipos de datos primitivos que vienen con Python incluyen booleanos, números (enteros de máquina, enteros de precisión arbitraria, y números de coma flotante reales y complejos), y cadenas de texto (de 8 bits y Unicode). Estos son todos tipos de datos inmutables, esto significa que los valores son representados por objetos que no pueden ser modificados después de su creación. Los tipos de datos compuestos que viene con el lenguaje incluyen tuplas (arrays inmutables), listas (arrays que pueden cambiar de tamaño) y diccionarios (tablas hash).

Para organizar los programas, Python soporta paquetes (grupos de módulos y/o paquetes), módulos (código relacionado agrupado en un solo archivo fuente), clases, métodos o funciones. Para control de flujo, provee if/else, while y una sentencia for de alto nivel que itera sobre cualquier objeto "iterable". Para el manejo de errores, Python usa excepciones. Una sentencia raise lanza una excepción, y las sentencias try/except/finally especifican manejadores para las excepciones. Las operaciones que vienen con el lenguaje lanzan excepciones cuando se encuentran condiciones de error.

En Python, todos los objetos que pueden ser nombrados son llamados "de primera clase". Esto significa que funciones, clases, métodos, módulos y todos los otros objetos nombrados pueden ser libremente pasados como parámetros, inspeccionados y almacenados en distintas estructuras de datos (por ejemplo, listas o diccionarios) en tiempo de ejecución. Y hablando de objetos, Python también tiene soporte completo para programación orientada a objetos; incluyendo clases definidas por el usuario, herencia y asociación de métodos en tiempo de ejecución.

Python tiene una extensa librería estándar, la cual es una de las razones de su popularidad. La librería estándar tiene más de 100 módulos y siempre está evolucionando. Alguno de estos módulos incluyen expresiones regulares, funciones matemáticas típicas, hilos, interfaces con sistemas operativos, redes, protocolos estándares de Internet (HTTP, FTP, SMTP, etc.), manejo de email, procesamiento de XML, procesamiento de HTML y toolkits para GUI (Tcl/Tk).

Además, hay una gran cantidad de módulos y paquetes provistos por terceros, muchos de los cuales también son open source. Aquí uno puede encontrar frameworks web (¡muchos como para listarlos!), más toolkits para GUI, librerías numéricas eficientes (incluyendo wrappers para muchos paquetes populares escritos en Fortran), interfaces con bases de datos relacionales (Oracle, MySQL y otras), SWIG (una herramienta para hacer que librerías C++ estén disponibles como módulos Python), y mucho más.

Un atractivo principal de Python (y de otros lenguajes de programación dinámicos en ese aspecto) es que tareas que parecen complicadas a menudo pueden ser expresadas con muy poco código. Por ejemplo, aquí hay un script en Python simple que obtiene una página web, la revisa buscando referencias a URLs, e imprime las primeras 10.

# Scan the web looking for references



import re

import urllib



regex = re.compile(r'href="([^"]+)"')



def matcher(url, max=10):

    "Print the first several URL references in a given url."

    data = urllib.urlopen(url).read()

    hits = regex.findall(data)

    for hit in hits[:max]:

        print urllib.basejoin(url, hit)



matcher("http://python.org")

Este programa puede ser modificado fácilmente para hacer un web crawler, y en efecto Scott Hassan me ha dicho que escribió el primer web crawler de Google en Python. Hoy, Google emplea millones de líneas de código Python para manejar muchos aspectos de sus operaciones, desde automatización a manejo de avisos (Descargo: en la actualidad soy un empleado de Google.)

Por debajo, Python es implementado como una combinación de intérprete y compilador a bytecode. La compilación es llevada a cabo implícitamente cuando los módulos son cargados, y muchas primitivas del lenguaje necesitan que el compilador esté disponible en tiempo de ejecución. A pesar de que la implementación de referencia de Python está escrita en C, y está disponible para cada plataforma de hardware/software existente, muchas otras implementaciones se han vuelto populares. Jython es una versión que corre sobre la JVM y tiene integración con Java. IronPython es una versión para la plataforma .NET de Microsoft que tiene una integración similar con otros lenguajes que corren sobre la plataforma .NET. PyPy es un compilador/intérprete de Python escrito en Python (aún un proyecto de investigación, financiado con fondos de la UE). También está Stackless Python, una variante de la implementación en C que reduce la dependencia del stack de C para llamadas a funciones/métodos, para permitir co-rutinas, continuations y micro hilos.

Traducido por Juan José Conti.

Revisado por César Portela.

Si encontrás errores en esta traducción, por favor reportalos en un comentario y los corregiremos a la brevedad.

Todas las traducciones de esta serie pueden encontrarse en La historia de Python.