El 20 de febrero de 1991, Guido van Rossum public\u00f3 en el grupo alt.sources el primer lanzamiento del lenguaje de programaci\u00f3n Python, en el que hab\u00eda estado trabajando desde diciembre de 1989, como parte de un proyecto para crear un lenguaje de scripting para resolver problemas de administraci\u00f3n de sistemas en el sistema operativo Amoeba, que fuera de un nivel m\u00e1s alto que C, pero a diferencia del Bourne shell, ofreciera un acceso m\u00e1s conveniente a las llamadas al sistema del SO. <\/p>\n
El nombre del proyecto fue elegido en honor al grupo de comedia Monty Python. En la primera versi\u00f3n, se implement\u00f3 el soporte para clases con herencia, manejo de excepciones, un sistema de m\u00f3dulos y tipos b\u00e1sicos como list, dict y str. La implementaci\u00f3n de m\u00f3dulos y excepciones fue tomada del lenguaje Modula-3, y el estilo de codificaci\u00f3n basado en la indentaci\u00f3n se inspir\u00f3 en el lenguaje ABC, en el que Guido hab\u00eda participado anteriormente. <\/p>\n
En el proceso de creaci\u00f3n de Python, Guido se gui\u00f3 por los siguientes principios: <\/p>\n
\n
Principios que permitieron ahorrar tiempo en el desarrollo:\n
\n
Tomar ideas \u00fatiles de otros proyectos.\n
La b\u00fasqueda de la simplicidad, pero sin simplificaciones excesivas (principio de Einstein: \u201cTodo debe explicarse de la manera m\u00e1s simple posible, pero no m\u00e1s simple\u201d).\n
Seguir la filosof\u00eda UNUX, seg\u00fan la cual los programas implementan una sola funcionalidad, pero lo hacen bien.\n
No preocuparse demasiado por el rendimiento; la optimizaci\u00f3n se puede a\u00f1adir seg\u00fan sea necesario, cuando sea necesaria.\n
No intentar luchar contra lo establecido, sino fluir con la corriente.\n
Evitar el perfeccionismo; normalmente, el nivel de \"suficientemente bueno\" es suficiente.\n
A veces, se pueden tomar atajos, especialmente si algo se puede hacer m\u00e1s adelante. <\/ul>\n
Los otros principios:\n
\n
La implementaci\u00f3n no debe estar atada a una plataforma espec\u00edfica. Algunas capacidades pueden no estar siempre disponibles, pero la funcionalidad b\u00e1sica debe funcionar en todas partes.\n
No abrumar a los usuarios con detalles que la m\u00e1quina puede manejar.\n
Apoyar y promover c\u00f3digo portable entre plataformas, pero sin restringir el acceso a las capacidades y peculiaridades de las plataformas.\n
Los grandes sistemas complejos deben ofrecer varios niveles de extensibilidad.\n
Los errores no deben ser fatales ni pasar desapercibidos: el c\u00f3digo del usuario debe poder interceptar y manejar errores.\n
Los errores en el c\u00f3digo del usuario no deben afectar la funcionalidad de la m\u00e1quina virtual ni conducir a un comportamiento indeterminado del int\u00e9rprete ni al fallo de procesos. <\/ul>\n