Identificadores No-Ascii en Python

[Hernan M Foffani]

> > 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...

Muchas gracias.
Es un buen esfuerzo.

> > === 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.

¿Te refieres a que hay gente que está tanto a favor como en
contra?

> ...  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.

He venido siguiendo la propuesta desde hace tiempo y debo decir
ciertas críticas me han dejado un mal sabor. Aunque no lo digan
con estas palabras hay algunos comentarios en la lista en inglés
que parecen temer que si se acepta la propuesta se abriría la
puerta a una horda de programadores del este que convertirán
a Python en ilegible.

> 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.

> 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.

La propuesta deja eso de lado. La verdad es que yo no lo veo tan
problemático (pero es la objeción principal de Guido así que mi
opinión es irrelevante.) Si alguien ha editado algún programa y ha
usado identificadores con eñes, cedillas o tildes apuesto a que
también habrá usado mogollón de cadenas de literales con estas
letras.

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.

A propósito, os recuerdo que Java, C# y apostaría que tambien
Visual Basic aceptan Unicode. Javascript los permite, además de
los identificadores en las expresiones regulares. Java lo viene
haciendo desde el principio de los tiempos y no ha pasado nada
(es mas hay mogollón de programadores que ni saben que podrían
escribir "this.Año = 2007;")

IronPython ya lo acepta para poder integrarse con .NET
Curiosamente, en ciertas situaciones, IronPython usa
identificadores con caracteres Unicode de los "raros" como
truco para evitar colisiones de nombres entre Python y .NET

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