Detalles sobre una instalación nueva de Ubuntu 12.04 en mi oficina

La gran pesadilla hasta ahora ha sido el proxy y el firewall de mi lugar de trabajo.
Desde las versiones 11.X de Ubuntu empecé a utilizar el entorno Unity de Ubuntu. Al principio no me gustó mucho pero empecé a entender las razones de su diseño: por ejemplo, el principio de que los píxeles valen [1]. Luego de darle una oportunidad y en la medida en que iba actualizando mi sistema hasta llegar al 12.04, creo que ya Unity tiene bastante madurez y puedo decir que me gusta el entorno. Ahora, en ese proceso he venido acarreando las aplicaciones que tenía instalada desde el 11.X y se que hubo muchos cambios en cuanto a las aplicaciones instaladas por omisión en un entorno Ubuntu. Así que por la curiosidad de entender qué es lo que la gente de Ubuntu define como su escritorio (si es que podemos seguir usando esa metáfora o ya es hora de pensar en una nueva) o mejor dicho, su sistema, quise hacer una instalación desde cero y darle una oportunidad a las aplicaciones que ellos sugieren y experimentar bien cómo se integran al resto del sistema (y cómo lo hacen, es algo que también me llama la atención); excepción: Emacs, ya instalado.
Sin embargo, hacer esto en una organización que tiene un firewall y un proxy clásicos, no es tan divertido. Así que quise dejar aquí algunas notas de las cosas que tuve que tomar en cuenta antes y después de la instalación desde cero en mi oficina.

[1]	Tal vez hago referencia a otro libro acerca de diseño, pero solo con ir a la Guía del escritorio de Ubuntu se puede uno enterara de que el diseño del nuevo Ubuntu busca minimizar las distracciones, aumentar el espacio de trabajo y ayudar al usuario a realizar sus tareas.

Respaldo

Por supuesto, este es el primer paso. Respaldar los datos importantes: documentos, imágenes, música, etc. Basta con copiarlos en un medio de almacenamiento externo como un CD/DVD o un disco duro externo.
Sin embargo, con respecto a los correos electrónicos y los contactos tuve que hacer algunos pasos adicionales.
Primero, he estado usando Evolution hasta ahora. Por ahora bastaría con el respaldo clásico, y se supone que importar esos correos desde Thunderbird es directo porque teóricamente usan el mismo formato de correo: Mbox. Sin embargo, hay una consideración en mi caso: había usado Evolution desde hace tiempo que me enteré que tenía los correos en un formato de correo viejo: Maildir que es mejor exportarlos a Mbox antes de hacer el respaldo, para que no tenga que instalar Evolution al final para poder transformar los correos a Mbox (tal vez no fuera necesario, pero era un riesgo que no tenía que pasar). Para esto, usé un script que recomendaron en una respuesta en AskUbuntu . Al final, el respaldo es un archivo en formato Mbox que debe guardarse en el medio de respaldo elegido.
Con respecto a los contactos desde Evolution, simplemente clic derecho a la libreta que se quiera respaldar y se exporta (normalmente a formato Vcard)
Luego del respaldo, viene la instalación. No escribiré al respecto, solo que instalé de la forma más directa: "siguiente siguiente siguiente".

La Red (el caso del Proxy)

Si tienes una computadora portátil, sufrirás las consecuencias de hacer todo lo que aquí se indica, porque cada vez que se cambie de lugar de acceso a Internet, habrá que volver a configurar el proxy.
Después de instalar el sistema lo primero que se haría es actualizar el sistema, pero esto no es tan trivial en mi oficina. Primero se debe configurar la red.
Si fuera el caso de una computadora nueva en la organización, habría que decirle al departamento de IT cuál es la dirección MAC de la máquina. Pero ya que estoy usando la misma máquina de siempre, no hace falta.
Luego, conectarse no debería ser muy difícil en Ubuntu: se conecta el cable y listo, o si se quiere usar la red inalámbrica, basta con colocar la contraseña cuando se pida.
La parte fastidiosa del cuento es el proxy.

Le Proxy

El malo de la película. No tienen idea cuánto lo odio, cuántas horas me ha hecho perder... ¡TE ODIO PROXY!. (Proxy suena a nombre de mujer, tenía que ser, que mujer tan enrollada).
El problema es que aparentemente soy la primera persona en la organización que no usa la Internet solo con Firefox, sino que a veces necesito wget y/o curl, bajar cosas con Emacs (paquetes de Emacs), Gwibber para el Twitter, todo el tema de APT para mantener mi sistema actualizado (y como no existe un repositorio en la organización...) o a veces conexiones no web: IRC y FTP por ejemplo (esta última parte no entiendo qué tiene que ver con el proxy, pero es así, aparentemente; si alguien puede explicarme por qué puede un proxy como squid fastidiar al IRC, se lo agradezco).
Bueno, empezamos con lo básico. La configuración del proxy en Ubuntu se hace en la configuración de red: SUPER seguido de 'red' y ENTER, o en el menú de configuración que se encuentra en el menú de arriba a la derecha.
Ahí hay una configuración por cada interfaz de red que tenga la máquina y por último está la configuración del proxy. Se puede determinar que no hay proxy; o configurar un proxy manualmente, en cuyo caso habría que colocar el nombre o la IP del proxy y el puerto; o, como en mi caso, la configuración automática, en donde se coloca la url de un archivo de configuración automático.
En un mundo ideal, esto debería bastar: todas las aplicaciones que eventualmente hagan uso de la web deberían verificar esta configuración para saber cómo usar el proxy. Pero en este aspecto, Ubuntu no es para nada ideal. Aquí una opinión: ¿Cómo es que con la configuración de red de Gnome basta para que todas las otras aplicaciones se puedan conectar a la red pero no puedan saber cuál es el proxy. El problema es peor y más triste aún: hay aplicaciones gráficas (de Gnome) que no usan esta configuración del proxy, por ejemplo Gwibber y Empathy (de hecho, hasta ahora no he podido resolver esto, así que me conecto al IRC por el webirc de Freenode).
Para que aplicaciones como wget y curl funcionen con el proxy, deben estar definidas las variables de entorno http_proxy y https_proxy.
Las variables de entorno http_proxy y https_proxy deben tener la url de conexión al proxy de la organización. Para que queden permanentemente establecidas esas variables, se coloca lo siguiente en el archivo .bashrc (ajustar a cada caso):

http_proxy="http://proxy.leorg.org:1080/"
https_proxy="https://proxy.leorg.org:1080/"
export http_proxy https_proxy

Todavía falta algo para poder hacer un apt-get update. Resulta que al hacer sudo apt-get update las variables de entorno se pierden, así que para mantenerlas hay que invocar sudo con la opción -E. Pero si queremos usar las interfaces gráficas de APT, como el Gestor de actualización o el Centro de software de Ubuntu hay un problema: ellos no los invocamos normalmente desde la consola, así que no tenemos tiempo de pasarles las variables de entorno a través del sudo.
La solución, seguir las recomendaciones de este artículo, editar el archivo apt.conf:

Acquire::http::Proxy "http://proxy.leorg.org:1080";
Acquire::https::Proxy "http://proxy.leorg.org:1080";

Pero hay un detalle que todavía causa problemas con las interfaces gráficas de APT y el proxy. A veces, un paquete invoca algún script durante el proceso de instalación, y este puede a su vez intentar conectarse a la web con programas como wget. Bueno, como es gráfico y obtuvo las credenciales por otro medio diferente de sudo (por lo cual no le pudimos decir con la opción -E que conserve las variables de entorno) entonces, ese wget no va a saber cómo conectarse al proxy. La solución, es fijar las variables de entorno del proxy al sudo. Para ello se usa el programa visudo y se agrega lo siguiente:

Defaults env_keep = "http_proxy https_proxy ftp_proxy"

Con todo esto, ya tenemos bien dominado a todo lo que es APT, y varias aplicaciones que no toman la configuración de Gnome, pero todavía me quedan pendientes:

1. Emacs y ELPA
2. Empathy
3. Gwibber

IRC no web es lo que más extraño.

Restauración

Para la restauración del respaldo, solo con respecto al correo y los contactos fue algo diferente a trivial (de resto, una simple copia).
Instalé el complemento de Thunderbird llamado ImportExportTools, luego hay que darle clic derecho a la bandeja de entrada, menú Importar/Exportar, opción Importar mbox y elegir Importar uno o más archivos con sus subcarpetas. En ese momento, una ventana de diálogo te permite elegir el archivo mbox a importar, que será el que se respaldó antes de instalar Ubuntu.
Los contactos se importan desde la vista de Libreta de direcciones, en el menú Herramientas, opción Importar.

Algunos paquetes que instalé luego

Emacs

La versión de Emacs que proveen los repositorios oficiales de Ubuntu es la 23. Pues la versión 24 trae una gran cantidad de mejoras que no quería perderme, entre los que más me interesan está el nuevo sistema de gestión de paquetes ya oficialmente soportado por Emacs.
Para poder instalarlo a la Ubuntu registré un PPA (Personal Package Archive) que mantiene unos paquetes de Emacs bien actualizados. Lo conseguí gracias a este artículo.
Los pasos que seguí:

$ sudo apt-get update
$ sudo add-apt-repository ppa:cassou/emacs
$ sudo apt-get update
$ sudo apt-get install emacs24 emacs24-el

Con esto ya tenemos el Emacs24 instalado. Irónicamente, el sistema de gestión de paquetes, la principal razón de instalar esta versión de Emacs, no funciona al 100% porque el proxy no le permite conectarse a los repositorios. Se puede configurar el proxy en Emacs, pero no he podido hacer que funcione todavía.
Otra cosa que tengo pendiente es instalar el soporte completo al idioma español en Emacs y el diccionario de Aspell.

Retoque a LibreOffice

De un excelente artículo acerca de cosas que retocar en Ubuntu después de instalarlo, rescaté, entre otras cosas, la habilitación del menú global para LibreOffice.
Lamentablemente en esta nueva versión de Ubuntu LibreOffice no hace uso del menú global, que es la nueva forma de interactuar con las aplicaciones en Ubuntu, exactamente igual que en MacOS. Se trata de que el menú de todas las aplicaciones se funde con la barra superior del sistema que ya contiene otras cosas como el espacio para las notificaciones, ahorrando bastantes píxeles verticales (que aparentemente son más importantes que los horizontales, ya que el lanzador no desaparece de manera automática como hacía antes).
Para hacer que LibreOffice respete el menú global, basta con instalar el paquete lo-menubar:

$ sudo apt-get install lo-menubar

Restricted Extras

Sin entrar en polémicas, por los mp3 y otros formatos de video:

sudo apt-get install ubuntu-restricted-extras

Cabe acotar que este paquete invoca a un script que intenta bajar archivos de la Web. Si el proxy no está configurado en sudoers (y en todos lados por si a caso) entonces fallará.

Y para escribir en el blog

• python-docutils
• rst2pdf
• mercurial

Solo faltaría configurar mercurial con por lo menos los datos personales del usuario:

$ cat > ~/.hgrc
[ui]
username = Jesús Gómez <jgomo3@gmail.com>
Ctrl-D

Siempre me toca hacer lo siguiente en el Terminal de Gnome

Estoy muy acostumbrado a las combinaciones de teclas de Emacs en el terminal, pero la tecla ALT y F10 disparan otros eventos propios del entorno gráfico (seleccionan el menú de la aplicación, en este caso el terminal de Gnome).
Para evitar que esto pase y funcionen como en Emacs, se modifican las configuraciones pertinentes en la opción Combinaciones de teclas... en el menú Editar. Ahí, se desactivan las teclas de acceso al menú y F10.

Decepciones

• ¡¡¡PROXY!!! No entiendo cómo no hay una solución única a este rollo.
• Tenía la esperanza de que una actualización limpia desapareciera ese bug de Firefox tan maldito: arrastra una imagen y TODO el sistema se congela por un minuto aproximadamente.

Mejorar como programadores - El Comienzo

La Idea

Inspirados en el artículo Kicking ass together: How to improve coding skills as a group, Luis y yo escribimos este artículo como un preámbulo a una etapa de trabajo en la que pretendemos implementar algunas de las ideas ahí planteadas.
El martes 10 de enero concertamos una reunión personal en el café de la nueva plaza de Los Palos Grandes. Muy buen lugar para el esparcimiento y reunirse. Tres copias impresas del artículo que se procesaron exageradamente con Readability (digo exageradamente porque pare ser sincero, no era necesario) sirvieron de guía durante la reunión, en la cuál principalmente hablamos de dicho artículo y de cómo llevar a cabo esas ideas aplicándolas en nuestro contexto.
El artículo es de gran interés para nosotros porque llevamos tiempo realizando reuniones que seguían más o menos esas ideas; pero al verlas condensadas en un solo texto, integradas, y ejecutadas inteligentemente, reconocimos su gran valor.
Otro artículo que nos motivó bastante fue 12 resolutions for programmers que apunta básicamente a las mismas motivaciones del primer artículo: Ser mejor persona para ser mejor programador (sustituye programador con lo que quieras y sirve igual). Queremos mejorar nuestras habilidades, de eso no hay duda, y sabemos que en Buen equipo lo haremos de mejor manera: más rápido, más amplio, más seguro (más probable).
La gente de Jelly hizo algo similar. El enfoque que le dieron es el de "vamos a llevar el ambiente de oficina a otra parte".
Al finalizar el año, haremos un análisis de lo logrado con este meta-proyecto.

El Grupo

Todas las ideas planteadas en los artículos mencionados (a excepción del de las doce resoluciones), o en las reuniones que hemos tenido, giran alrededor del concepto de un grupo. Sería entonces el medio más importante para lograr el objetivo de mejorar personalmente. Así que uno de los primeros objetivos a corto plazo sería la consolidación del mismo.
Siguiendo las recomendaciones de los textos, y la experiencia propia, planteamos al grupo como un ente orgánico, en el sentido de que su evolución sea lo más natural posible, es decir, no forzaremos su crecimiento, las iniciativas deben venir de las bases y los objetivos y actividades serían planteadas en función de la madurez del grupo, es decir, ya tendremos tiempo para un BigDeepShitCON, pero por ahora, proyectos concretos y tangibles en corto plazo son nuestros objetivos.
Como ejemplo de estos proyectos:

Hack 7 Languagess in 7 weeks

El libro Seven Languagess in Seven Weeks pretende explicarle a entendidos en la programación, siete lenguajes representativos de los más diferentes paradigmas de programación. Entonces, como actividad de grupo nos hemos planteado leer este libro y comentarlo entre nosotros, hacer los ejercicios y comparar las soluciones y/o simplemente apoyarnos mutuamente en el seguimiento del mismo.

Track le blogs

Una de las resoluciones asumidas fue la de mantener un blog. Entonces, en el grupo nos apoyaremos leyendo los blogs de los compañeros y generando feedback.

Maratonear

Para mantener a punta nuestras habilidades esenciales de la programación, haremos ejercicios concertados de programación clásicos de los maratones. Como ejemplo, los problemas de spoj, luego de solucionarlos, compararemos las soluciones, y también discutiremos ideas durante el desarrollo de las soluciones.

Desarrollo de aplicaciones

Siempre surgen ideas de aplicaciones útiles durante las reuniones. Podemos ejercitar el trabajo en un buen equipo de desarrollo de software implementando estas ideas en el marco del meta-proyecto.

Para materializar los resultados esperados, el trabajo se realizaría en sesiones presenciales y no presenciales.

Sesiones de trabajo presenciales

Con el objetivo claro de mejorar y tomando el artículo como guía, nos propusimos realizar un conjunto de sesiones periódicas de trabajo. Éstas consistirán en una hora de trabajo y una hora de socialización. Entendemos que, para mejorar, ambas actividades son igual de importantes.
Las sesiones de trabajo deben incorporar actividades que mejoren las habilidades de cada uno de los participantes. Algunas de las actividades que identificamos que cumplen con este requisito son solucionar problemas de programación, hacer code reviews, etc.
En estas sesiones de trabajo, también se podrán realizar charlas de interés para los participantes del grupo.
Las sesiones de trabajo y socialización están abiertas a cualquiera que quiera asistir a ellas, y la única condición es participar y aportar desde el primer momento. Cualquier comentario dentro de contexto se considera participación.

Sesiones de trabajo en linea

Siguiendo el ejemplo de numerosos proyectos de Software Libre, resulta sencillo ejecutar de manera remota casi la totalidad de las actividades que nos hemos planteado. Nos referimos a las herramientas clásicas de las que se valen estos proyectos para coordinar el trabajo de tantos participantes localizados en lugares remotos del globo, a saber: Sistemas de Control de Versiones Descentralizados, documentación en línea, IRC, wikis, blogs, etc.

El Comienzo

Puede interpretarse como una nueva disciplina. Tal vez como un simple programa de ejercicios rutinarios. Tal vez un hobby. En cualquier caso, se trata de algo positivo.
Pero lo que sí es cierto, es que lo que hemos escrito, es los planes de su primera etapa (sea lo que sea).

Ciclo redactar publicar con Blogger

Tengo la intención de escribir varios artículos en este blog:

• Despliegue en Django
• Mi presentación de Git
• La conferencia Mejorando la web
• Cita al ensayo sobre SOPA creado por @danielmaxx
• Algunas cosas viejas que escribí por ahí

Pero habiendo colaborado en algunas revisiones de El blog en español de Python Insider quise poner en práctica el mismo workflow que ellos aplican. Y es lo que estoy haciendo justamente ahora mientras escribo este artículo acerca del mismo workflow (y lo que haré de ahora en adelante).

Le workflow

El mencionado workflow está explicado en el wiki del proyecto de los blogs de Python. Pero básicamente se basa en utilizar un repositorio bajo control de versiones donde un convenio en el uso de los directorios permite distribuir el trabajo.
La parte interesante del workflow es que el trabajo de redacción no se hace en la interfaz que para ello disponga el sitio que almacena y publica los artículos (en nuestro caso, la interfaz web de Blogger), sino que se redacta en un archivo dedicado al artículo, y ese archivo se mantiene en control de versiones. Luego, cuando se esté conforme con el resultado, se publica utilizando un script que sube el archivo como si fuera el artículo (también pudiera usarse el copiar y pegar con la interfaz web).
En particular, el proyecto de los blogs de Python utiliza mercurial como sistema de control de versiones, bitbucket es donde almacenan su repositorio, reStructuredText es el lenguaje de marcas que utilizan para estructurar y formatear los artículos y un script en Python [1] muy específico para subir el archivo al blog.
Una de las más grandes ventajas de trabajar de esta manera es el soporte en la coordinación del trabajo de varias personas sobre el mismo producto que se obtiene al usar el sistema de control de versiones y un repositorio compartido.
Pero cuando se usa para un blog como el mío que solo tiene un autor, todavía hay ventajas.
Primero, el control de versiones. Pero esta vez, en vez de referirme al poder de coordinación, me refiero a la ventaja de contar con versiones que reflejen la evolución de lo que escribo y poder echar para atrás los cambios que quiera.
Segundo, escribir en tu lenguaje de marcas preferido ... punto.
Tercero, escribir en tu editor de texto preferido ... punto.

Ejemplo

Como ejemplo de cómo trabajar con este workflow voy a explicar cómo he escrito esta entrada y cómo lo publiqué.

Le script

El script en Python se llama rst2blogger.py. Se usa la siguiente manera:

$ rst2blogger.py <blog> <.rst>

Lo que hace es convertir el archivo .rst en un contenido en formato html y trata de subir ese contenido en el blog blog. Para ello te pide que te autentifiques con los servicios de Google.
Como este es un script que rápidamente se hizo para este workflow de los blogs de Python, entonces hay que modificarlo un poco para que sirva con el de uno.
Lo primero que hace el script después de todos los imports es definir un diccionario llamado BLOG_IDS, asocia una etiqueta al identificador único del blog. Entonces, simplemente se añade el blog de uno en ese diccionario. Por ejemplo, el identificador único de mi blog es 15836385 [2], entonces asocie el identificador jgomo3 con él. Queda algo así:

# local
import rst2post

BLOG_IDS = {
    'jgomo3':'15836385',                # jgomo3's blog
    'clienttest':'4574580403850978202',

Hay que aclarar dos cosas acerca del script:

• Él pica el contenido en dos partes: el título, y el resto. Entonces, el título con el que sube el artículo va a ser el que le coloques como título principal en el .rst.
• La primera vez sube el artículo como un borrador nuevo. Las siguietes veces que publique el mismo blog, simplemente actualiza el blog. Para publicar, se hace desde la interfaz administrativa de Blogger.

Como alternativa a este script, pudiera lograrse algo parecido con una combinación entre rst2html y googlecl.

Le repo

Creé un repositorio en bitbucket para mantener el blog (de ahora en adelante).
Luego, lo cloné en mi máquina para trabajar:

$ hg clone https://bitbucket.org/jgomo3/jgomo3-blog

Siguiendo el convenio de los blog de Python, definí dos directorios:

• InProgress: que contiene los artículos "en progreso", es decir, los borradores.
• Published: que contiene los artículo ya publicados en el blog.

$ install -d InProgress Published

Entonces, el trabajo es evidente. Cuando se quiere empezar un nuevo artículo, simplemente se crea un archivo en la carpeta InProgress. Luego, un hg add para hacerle seguimiento con mercurial. hg commit por cada cambio relevante que queremos recordar con mercurial y cuando queramos salvaguardar el trabajo en bitbucket, un hg push (así además puedes mostrar el trabajo a terceros para que le echen un ojo y si quieren pueden colaborar).

$ cd InProgress
$ hg add ciclo-redactar-publicar-blogger.rst

... Ciclo largo de trabajo
.
.    ... Ciclo corto de trabajo
.    .   $ [tu editor favorito o emacs] ciclo-redactar-publicar-blogger.rst
.    .   $ rst2html ciclo-redactar-publicar-blogger.rst > test.html
.    .   # Ver el archivo test.html en un navegador
.    ...
.
... $ hg commit

$ hg push

Le blog

Una vez esté terminado el artículo y se quiera publicar en el blog, se ejecuta el script:

$ rst2blogger.py jgomo3 ciclo-redactar-publicar-blogger.rst

Esto creará un borrador en Blogger. Entonces se navega a Blogger, se aprecia cómo se ve el borrador, se le asigna la fecha de publicación al artículo y se publica.
Por último, se mueve el artículo de la carpeta InProgress a la carpeta Published y se actualiza el repositorio en bitbucket:

$ hg mv ciclo-redactar-publicar-blogger.rst ../Published
$ hg commit
$ hg push

Le FIN

Como ya comenté, de ahora en adelante usaré esta técnica para escribir en el blog.
Por último, por si no lo notaron, mi editor favorito es Emacs, y dejo a su disposición un par de artículos que explican esta misma idea pero desde el punto de vista de un par de emacseros y usuarios del org-mode.

• emacs-fu way
• Andrei's way

[1]	Deben estar todos los archivos .py en el mismo lugar.

[2]	Para saber cuál es el identificador único de tu blog en Blogger simplemente observa la barra de direcciones de tu navegador mientras lo editas.

Huxley

La historia muestra que la mente humana, alimentada por constantes accesos de conocimiento, crece periódicamente demasiado para soportar los recubrimientos teóricos, y explota en pedazos para aparecer con una nueva vestimenta, de la misma manera que la larva en crecimiento, cada cierto tiempo, se deshace de una piel demasiado estrecha y se viste con otra, que de nuevo será temporal. Ciertamente, el estado de imago del Hombre parece estar terriblemente distante, pero cada muda es un paso ganado, de los que habrá muchos. [] … una nueva ecdisis parece inminente.

Thomas H. Huxley.

Fuente:

• Ecdisis inminente - Amazings.es

Recuerdos de Pandora

Un excelente blog con artículos de científicos y de interés general.
Este blog lo leo a diario, encuentro la totalidad de sus artículos muy interesantes y de un buen nivel y siempre cuenta con las respectivas fuentes para el que quiera profundizar más en el tema.
Al leer cualquiera de sus artículos, se apreciará la dedicación que se da a cada uno de ellos.
Bueno, simplemente quiero dedicar esta entrada a recomendar que lo lean, suscribanse y si les gusta de verdad, voten por él

Python ¿qué tiene 3 que no tenga 2?

Esta inquietud ha rondado por la cabeza de muchos desde que salió Python 3.0. En la lista de python-caracas Nhomar hace una pregunta simlar que se reduce a "Técnicamente, cuáles son las ventajas que traerá el python 3.X???". Más allá de los detalles menores como el hecho de que print ya no es una sentencia del lenguaje sino una función integrada, la inquietud real es saber ¿qué tiene Python 3 que no tenga Python 2?.

Luego de leer al respecto en varias fuentes, la respuesta que daré puede ser rara para algunos: nada. De echo, tiene menos. Quieren probarlo, solo les diré que es más fácil hacer que un código en Python 3 corra en Python 2 que lo contrario: puede verse a Python 3 como un subconjunto de Python 2.

No quiero escribir sobre lo nuevo de Python 3 (ya que pueden encontrar mucho material al respecto) sino de lo que he entendido fue la inspiración de Python 3.

Python 3 fue diseñado para honrar el principio "debe haber una-- y preferiblemente una --manera obvia de hacerlo" del Zen de Python[1].

Python 3 ha sido un intento por pulir aún más este lenguaje de pequeños detalles que sus creadores sentían incómodos y existían solo para mantener la compatibilidad hacia atrás del lenguaje. La solución fue eliminar esta compatibilidad. Parafraseando a Guido: "Es una oportunidad que él mismo se está dando para corregir esas decisiones de diseño equivocadas que tomó al principio del desarrollo de Python que no podría corregir sin romper el código de todos"[2].

Los cambios en la biblioteca dan testimonio de que se trata de una cuestión de honrar el sentido común en el diseño del lenguaje, pero sobre todo el Zen de Python referido. Por ejemplo:

• Renombrar los módulos para que todos los nombres cumplan con la guía de estilo de Python (una sola forma de nombrar los módulos).
• Eliminar la costumbre de tener dos nombres de módulos (uno de ellos con una c prefijada) si había una versión rápida implementada en C (un solo nombre de módulo).
• Agrupar los módulos parecidos en un paquete común, por ejemplo, md5 y shasum ahora forman parte de hashlib (un solo punto de acceso para algoritmos similares).

La forma en que se trabaja con el texto es una evidente y clara forma de honrar el Zen. Ahora las cadenas son cadenas son cadenas y eso es todo (sí, énfasis redundando). Y si necesitas una manera de interactuar con los bytes que representan las cadena, tienes el tipo bytes y métodos para codificar una cadena en una secuencia tipo bytes. Todo está más claro ahora y bien separado.

Sin embargo, Python 3 trajo nuevos elementos al lenguaje, como la sentencia with, y la comprensión de conjuntos y diccionarios. Pero estos elementos han sido portados a Python 2 para hacer la transición a Python 3 más fácil.

[1] http://en.wikipedia.org/wiki/Python_3000#Version_3.0
[2] http://www.youtube.com/watch?v=s-fKcZ5pKLE#t=2m20s

Más enlaces sobre el tema:
http://www.b-list.org/weblog/2008/dec/05/python-3000/
http://diveintopython3.org/
http://www.ibm.com/developerworks/linux/library/l-python3-1/

Calendario de python-caracas

Actualización: Esta información ya no es relevante. El grupo python-caracas ya no existe, se fusionó con Python Venezuela.

Para mantener más organizado al grupo creé un simple calendario de Google dedicado a python-caracas. Pueden verlo si bajan un poco la página podrán ver el calendario en la columna derecha.