Historias
Slashboxes
Comentarios
 
Búsqueda

Login Barrapunto

Login

[ Crear nueva cuenta ]

mig21 (7781)

mig21
  reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw
Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames ;)

No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...

Esta es toda mi información de usuario :)

Down Kill Up Publicidad

Bitácora de mig21 (7781)

Miércoles, 20 de Junio 2007

Guido, sobre los planes de Python 3.0

09:52h.
Python

En su bitácora de Artima Guido van Rossum ha actualizado las previsiones que tiene acerca del proyecto llamado 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() (que fue explicada en The fate of reduce() in Python 3000)

Al parecer romperá uno de los tabúes más sagrados de la informática: 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, van a echar a faltar reduce()

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Guido escribe sobre los planes de Python 3.0 | Log in/Crear cuenta | Top | 54 comentarios | Buscar hilo
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) <reversethis-{se.oohay} {ta} {46nizezep}> 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!

  • Unicode, bienvenido seas.

    (Puntos:1)
    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())?

  • Me parece mal que el tipado estático sea opci

    (Puntos:2)
    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.

  • Tampoco estaría mal

    (Puntos:2)
    por juatman (11608) el Miércoles, 20 Junio de 2007, 19:05h (#925081)
    ( Última bitácora: Jueves, 21 Junio de 2018, 05:03h )
    Que la identación fuese opcional, pudiendo sustituirse por "{" y "}", o por "begin" y "end". ;-)

  • ¿Soy el unico traumatizado con fortran?

    (Puntos:2)
    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: Domingo, 08 Julio de 2018, 16:42h )
    paz= guerra
    libertad= esclavitud
    fuerza= ignorancia
    --

    __
    Comprare è combattere.
    [ Padre ]
  • 2 respuestas por debajo de tu umbral de lectura actual.