Historias
Slashboxes
Comentarios
 

Guido escribe sobre los planes de Python 3.0

Entrada escrita por mig21 y editada por rvr el 20 de Junio 2007, 11:09h   Printer-friendly   Email story
desde el dept. pythonisos
En su bitácora de Artima, Guido van Rossum ha actualizado las previsiones de Python 3000 (que acabará siendo python 3.0). Repasa las novedades de las versiones 2.6, que será versión puente y la 3.0. De esta última destacan el tratamiento de Unicode y entradas y salidas, el sistema de clases y tipos (con "anotaciones" que se podrán usar como tipado estático opcional), cambios en excepciones y enteros y algunos otros cambios como la eliminación de reduce. Al parecer romperá la compatibilidad hacia atrás, aunque habrá herramientas de conversión entre la versión 2.6 y la 3.0. Lo comentan entre otros sitios en Lambda the Ultimate: Python 3000 Status Update, en donde, por supuesto, va a echar a faltar reduce.

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Interesante...

    (Puntos:2, Interesante)
    por pezezin (11919) <pezezin64NO@SPAMyahoo.es> el Miércoles, 20 Junio de 2007, 11:33h (#924903)
    ( http://barrapunto.com/ | Última bitácora: Viernes, 17 Noviembre de 2006, 23:39h )
    Lo de reduce() ya lo sabía todo el mundo. A Guido no le gusta la programación funcional, así que es lógico que intente "reducirla" (:P). De todas maneras, reduce() no es muy difícil de implementar, siempre y cuando el lenguaje tenga buen soporte para recursividad (cosa que Python tampoco tiene, pero bueno).

    En cuanto al tipado estático opcional, considero que es interesante. Una de las cosas que menos me gusta de los lenguajes dinámicos es que nunca estás seguro de si una función va a ejecutarse correctamente o no hasta que la llamas. El tipado estático puede ayudar en este sentido.
    --

    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

  • por groonan (29142) el Miércoles, 20 Junio de 2007, 12:13h (#924919)
    Olé, olé y olé por el soporte unicode (UTF-8) por defecto, esperemos que el "parser" dejará de quejarse tanto en cuanto encuentre un carácter no ASCII. Creo que en python 2.5 hasta cascaba... Yo seguiré sin utilizar caracteres raros, pero al menos podré poner mi nombre: Andrés. Del resto por ahora no comento, que semejante tocho necesita tiempo en casita para ser analizado.
    --
    Ningún hombre es tan tonto para desear la guerra y no la paz; decía Heródoto. Lástima que estuviera equivocado.
  • reduce() todavía pero ¿map()?

    (Puntos:2, Interesante)
    por bugmenot (27209) el Miércoles, 20 Junio de 2007, 13:03h (#924931)
    Es verdad que reduce() ahora sólo se usa casi como sum() o como un futuro product() pero map() es fundamental. Con generadores de listas y dos o más argumentos a partir de los que generar el intérprete se hunde. Por ejemplo (cambio los espacios de tabulación por _ porque barrapunto no parece que los permita):

    from operator import mul
    import time

    many_times = xrange(1 << 24)

    s_addr = '127.0.0.1'
    byte_weight = [ 1 << i for i in range (24, -8, -8) ]

    t1 = time.time()
    for i in many_times:
    --------sum(map(mul,
    --------------- -map(int, s_addr.split('.')), byte_weight))
    t2 = time.time()
    print t2 - t1

    t1 = time.time()
    for i in many_times:
    --------sum ([ x * y for x, y in zip(
    ----------------[int(x) for x in s_addr.split('.')], byte_weight)])
    t2 = time.time()
    print t2 - t1

    La primera, con map(), es como el doble de rápida en 2.5. ¿Hay otra forma de codificar el segundo ejemplo sin map() y más rápido que con ella (sin zip())?
  • por knocte (3563) el Miércoles, 20 Junio de 2007, 13:24h (#924938)
    ( http://knocte.blogspot.com/ )
    Me parece mal que el tipado estático sea opcional, aunque también es verdad que por algo se empieza.

    Cuando dentro de unos años pase a tener tipado estático obligatorio, es probable que le dé tanta importancia como a Java o C# (u otros estáticos de Mono).
  • Como matemático

    (Puntos:2, Inspirado)
    por pedro_fortuny (29526) el Miércoles, 20 Junio de 2007, 16:14h (#925002)
    Pienso que eliminar map() de un lenguaje de programación solo significa que alguien va a implementarlo y distribuir la librería al día siguiente. Sí, es una función poco "objetiva" si diferencias código y datos. Porque al final, quien tenga "problemas" con map() es porque entiende que es poco "ortodoxo" un s.map(lambda(a,b) {a+b}) donde s = [[u1,v1],....[un,vn]] es una lista de pares. Por poner el ejemplo canónico, vaya. Y creo que es por diferenciar entre s ("datos") y lambda ("código"). Pero esto es una opinión personal sobre opiniones de otros...... Creo yo, claro. Pero de todos modos, yo no sé Python. Pedro.
  • por juatman (11608) el Miércoles, 20 Junio de 2007, 19:05h (#925081)
    ( Última bitácora: Lunes, 15 Noviembre de 2010, 20:14h )
    Que la identación fuese opcional, pudiendo sustituirse por "{" y "}", o por "begin" y "end". ;-)
  • por Endymion (27848) el Jueves, 21 Junio de 2007, 04:26h (#925195)
    Debo ser el único que se traumatizó con Fortran, porque no veo a nadie aullar de dolor por el hecho de que se vaya a reemplazar el operador "%" por llamadas a format()
    --
    A la guerra de los pobres la llaman terrorismo. Al terrorismo de los ricos lo llaman guerra.
  • Python 1984

    (Puntos:1)
    por Ricardo Estalmán (102) el Miércoles, 20 Junio de 2007, 19:47h (#925100)
    ( http://barrapunto.com/tags/restalman | Última bitácora: Miércoles, 24 Noviembre de 2010, 22:39h )
    paz= guerra
    libertad= esclavitud
    fuerza= ignorancia
    --

    __
    Waxing pessimistic is one of the easiest ways to masquerade as wise, Alvin y Heidi Toffler.
    [ Padre ]
  • 2 respuestas por debajo de tu umbral de lectura actual.