Identificadores No-Ascii en Python

[Hernan M Foffani]

El 16/05/07, Chema Cortes <py en ch3m4.org> escribió:
> El Martes, 15 de Mayo de 2007 22:43, Hernan M Foffani escribió:
>
> > > > Hay gente a favor y gente en contra. El problema en la discusión es que
> > > > quienes opinan, mayormente tienen el ingles como idioma nativo asi que
> > > > la opinion no es del todo imparcial. Por eso conviene que gente como
> > > > nosotros opine sobre este cambio. Asi que, qué les parece?
> > >
> > > Yo no pienso que los hispanoparlantes tengamos un punto de vista
> > > radicalmente distinto a los angloparlantes en este tema.
> >
> > ¿Te refieres a que hay gente que está tanto a favor como en
> > contra?
>
> Más bien a que nuestras necesidades en este tema tampoco difieren mucho.

En ese caso, disiento en eso de "nuestras necesidades".

> > > ...  A parte de
> > > querer poner "eñes" para que no quede tan feo poner 'año' con ene,
> > > poca ventajas más aportaría (aunque más de uno encontraría la ocasión
> > > para usar símbolos monetarios como el euro sin venir a cuento).
> >
> > En la práctica, para los idiomas latinos, el conjunto ASCII se queda
> > corto en un par de letras mas las tildes.  No es grave (para nosotros
> > al menos) pero por eso mismo no el problema en incorporar la
> > novedad.
>
> Idem de lo anterior.

Se suele olvidar que Python puede y de hecho es mi principal caso de uso,
que es un lenguaje que puede ser empotrado en aplicaciones y extendido
mediante bibliotecas. En éstos casos lo que prima es la especialización
del dominio de la aplicación. Permitir que los usuarios puedan
escribir sus personalizaciones (scripts, tasklets, etc.) en el idioma
original es bueno.

> De todos modos, como físico que soy, reconozco que a veces me gustaría poder
> expresar las fórmulas matemáticas con los símbolos griegos y matemáticos
> habituales (pe: el número Pi). Resultaría de cierta ayuda en la documentación
> ("programación literaria").
>
>
> > > En cuanto a la implementación, hay que saber cómo afectaría al actual
> > > mecanismo de "internalización" de strings (función "intern()", similar
> > > a los símbolos de ruby/ss).
> >
> > En la versión 3, todos los strings serán Unicode así que no habrá
> > ningún problema con eso.
>
> El problema está en la pérdida de rendimiento cuando se busque dentro de la
> tabla de símbolos. No es lo mismo tener ordenados los símbolos por código
> ascii que por unicode; aunque seguro que se habrá tenido en cuenta.

No se si me pierdo algo porque no veo el problema. Recuperar un
nombre del diccionario interno es O(1). Calcular el hash de una
cadena unicode es lo mismo que para una cadena ascii.
Además, TODAS las cadenas serán unicode en python 3.

> > La codificación estándar para la versión 3 será UTF-8 así que los
> > programadores tendrán que usar las herramientas adecuadas a partir
> > de entonces.
>
> Al igual que no ha sido suficiente con ascci ni latin1, tampoco será
> suficiente con utf8. Los países asiáticos prefieren usar utf16 porque ocupan
> menos sus cadenas de caracteres y, además, se procesan más rápidas. Supongo
> que tendrán que esperar para la versión 4.