Identificadores No-Ascii en Python

[tny]

El mar, 15-05-2007 a las 20:16 +0200, Chema Cortes escribió:
> 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.ç

Pues yo también estoy de acuerdo en que se puedan incluir carácteres
no-ascii, tal vez discrepo un poco en el modo de implementarlo, (yo lo
haría mediante algún tipo de secuencias de escape, lo que se puede hacer
sin tocar para nada el sistema actual, se puede hacer incluso con
plugins en los editores)

------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es