python 3.0

[Hernan Martínez-Foffani]

> >> Una característica que distingue a python es que se mantiene muy bien la compatibilidad con
> >> las versiones anteriores.
> > Ahora que lo comentas, Guido Van Rossum anuncia en artima:
> > http://www.artima.com/weblogs/viewpost.jsp?thread=98196
> > que va a eliminar lambda, map() y reduce() en python 3.0
> > dice que no va a mantener compatibilidad con las anteriores versiones...
>
> 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.

Sólo para evitar confunciones, Python *no* tendrá "tipado estático opcional".
Lo que incorporará es una sintaxis para anotación de información a
funciones.  En el momento de compilación, esa información se convertirá
en un diccionario vinculado al atributo de función func_annotations.
La especificación permite usar expresiones cualesquiera (no sólo tipos)
como anotaciones.

Ejemplo (escrito sin probar):

>>> def funcion(a: sum, b: "otra") -> 4 + 2:
...     pass
>>>
>>> print( funcion.func_annotation )
{ 'a': <built-in function sum>, 'b': 'otra', 'return': 5 }
>>>

Python (el lenguaje) no asume *ninguna* semántica a las
anotaciones. Los usuarios serán libres de darles el
significado que mejor les convenga.


>
> Lambda no se elimina (la quita y los Lisperos le montan un fork :-)):
>
>  > lambda, however, lives. (...) Did I mention that lambda lives?
>
> Map no le elimina, se vuelve iterable:
>
>  > zip(), map(), filter() return iterables (like their counterparts in itertools
>  > already do).
>
> Y "reduce" desaparece... para aparecer en functools. O sea, que tampoco hay que
> hacer un drama.

10 años con Python y sigo sin entender por qué siempre hay tanto lío con
lambda y cía.

> Mucho más significativo es que se diferencia el tipo cadena (que será siempre
> unicode) y el type bytes (¡mutable!). Me parece una buena decisión.
>
> 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.

Como ya explicó Guido la sintaxis del % tiene muchísimos problemas.

> ¿Algún comentario de lo que cuenta Guido?

No tengo nada que objetar (dicho como si realmente pudiera ;-).
Me gustan la nueva IO, la unificación de str y unicode, el tipo bytes,
identificadores unicode.

En particular aprecio muchísimo las clases abstractas (y la estructura
de ABCs propuesta para la biblioteca estándar).  Para un lenguaje
con herencia múltiple (algo que muchos se olvidan), es la solución
mas natural.

Sólo espero que se puedan resolver los cabos sueltos que quedan sobre
funciones genéricas. Sería una técnica de programación formidable.

Saludos,
-H.