python 3.0

[Chema Cortes]

El 21/06/07, Arnau Sanchez <arnau en ehas.org> escribió:

> No es exacto, ya se habló ayer en Barrapunto:
>
> http://barrapunto.com/articles/07/06/20/1055242.shtml
>
> ¡Deberíamos tener aquí más reflexiones como ésa! Incluso leeríamos a Chema, que
> llevaba unos días desaparecido :-) Es interesante ver la opinión de gente no tan
> directamente relacionada con Python; por ejemplo, el interés generalizado en el
> tipado estático opcional (no creo que suceda por el momento), que parece
> obsesionar a los que vienen de otros lenguajes.

Se agradece el "recuerdo". Como bien sugieres, tengo poco que añadir a
las completas respuestas que se dan en la lista; pero sigo estando por
aquí.

> Aunque sólo sea un detalle, me sorprendió que se elimine el operador % para
> cadenas, ahora se usará la función "format". Imagino que la refactorización
> automática será muy simple, pero en cualquier caso choca no poder usarla en el
> futuro.
>
> ¿Algún comentario de lo que cuenta Guido?

Particularmente, no me gustaba nada la sintaxis del operador de
formato: poco legible y generador de bastantes errores. Veo más
coherente y lógico usar un método 'format' de string del mismo modo
que usamos los métodos join o split. Así mismo, la nueva forma de
pasar argumentos (posicionales y nominales) al format permite
sobrecargar este método de conversión a cadena para cada clase.

También creo acertada la decisión de pasar el 'print' de sentencia a
función. De este modo, se pueden personalizar la función 'print' para
que funcione de otra manera (salidas simultáneas a terminal y fichero,
formateo de la salida en html, etc).

En cuanto al resto de cosas novedosas, me da que tardaremos bastante
en verlas, e incluso que no las veremos nunca. Cosas como la
"comprensión" para sets no lo veo nada claro, empleando las llaves que
las confundirían con los diccionarios e hipotecaría la sintaxis para
una futurible "compresión" de diccionarios.

En cuanto a lo de sugerir el tipo de dato en los argumentos de entrada
tampoco lo veo claro, a pesar de que haya sido aceptado con cierto
entusiasmo en la comunidad python: sería necesario añadir el
"polimorfismo" para que fuera completo. Guido habló de introducir
nuevos decoradores que etiquetaran las funciones como "multislot" de
modo que se pudiera contar con múltiples definiciones de una misma
función según el tipo de los argumentos de entrada; pero veo que se
complica demasiado la sintaxis de python, con funciones con dos modos
de comportarse (las que se redefinen y las que no), amén de que
empezaría a ser extremadamente complicado depurar el código
"multislot".

Añadiendo cosas, creo que se debería introducir un "finalizador" de
bloque. Ayudaría a poder incrustar código python en otros códigos (eg:
python en html para programar páginas web) y ayudaría a resolver la
eterna polémica de las funciones lambda si se hiciera al estilo lua:

#sintaxis ficticia mezcla lua-python
operaciones={
      "+":function (a,b) return(a+b) end,
      "-":function (a,b) return(a-b) end,
      "*":function (a,b) return(a*b) end,
      "/":function (a,b) return(a/b) end
}

resultados=[f(1,2) for f in operaciones.values()]


Para una hipotética compresión de diccionarios:

res_dict={[k]=f(1,2) for k,f in operaciones.items()}


Lua tiene muchas cosas interesantes en la que python podía inspirarse.