[Python-es] Identificadores No-Ascii en Python

[Chema Cortes]

El 15/05/07, Gabriel Genellina <gagsl-py2 en yahoo.com.ar> escribió:

> En la lista en inglés de Python se puso a consideración esta propuesta:
>
> PEP: 3131
> Título: Soporte de Identificadores No-ASCII
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/ebb6bbb9cc833422/a4a0141d6c4cd1ed?#a4a0141d6c4cd1ed
>
> Básicamente sugiere soportar letras no-ASCII (como caracteres acentuados,
> cirílicos, griegos, kanji, etc) como identificadores Python.
> Si fuera aceptada, los siguientes serían identificadores válidos para
> clases, funciones o nombres de variable: Löffelstiel, changé, ошибка, or 売
> り場 (confiando que este último signifique "contador").
>
> Aca va un intento de traducción - hice lo mejor que pude...
>
> === begin ===
>
>[...]
>
> === end ===
>
> 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. 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).

Creo que nuestra forma de programar tiende más a usar los términos en
español como un "espacio de nombres" aislado de los nombres en inglés
propios de los objetos de la librería estándar y del resto de módulos.
Un ejemplo sería el mensaje del otro día en el que un campo llamado
'year' chocaba con el nombre de una función de la base de datos.

Un uso más justificado sería en el nombre de los atributos de una
clase. Muchas veces queremos que el diccionario de nombres de una
clase coincida con los nombres de los campos de una tabla, y no tener
que reconvertir los identificadores para ajustarlos a la norma del
lenguaje utilizado.

Como bien dicen en el PEP, debería ser una decisión del programador y
no del lenguaje. Aún con todo, estamos hablando sólo de
identificadores, no de las estructuras básicas como if..then ó
for...in, ni tampoco de traducir los nombres de la librería estándar.

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). También preferiría que, de modo visual, se
pudiera distinguir estos identificadores extendidos en el caso de que
el usuario no cuente con los medios para visualizar correctamente el
código; por ejemplo, encerrar el identificador entre corchetes de
algún tipo. Creo que es esto último lo más a tener en cuenta.