[Python-es] Identificadores No-Ascii en Python

Gabriel Genellina gagsl-py2 en yahoo.com.ar
Mar Mayo 15 10:47:13 CEST 2007


Hola

(Crossposteado en gmane.org.user-groups.python.argentina y  
gmane.comp.python.general.castellano)

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 ===
PEP: 3131
Title: Soporte de Identificadores No-ASCII
Version: $Revision: 55059 $
Last-Modified: $Date: 2007-05-01 22:34:25 +0200 (Di, 01 Mai 2007) $
Author: Martin v. Löwis <mar... en v.loewis.de>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History: Traducción al español por Gabriel Genellina

Resumen
=======

Este PEP sugiere soportar letras no-ASCII (como caracteres acentuados,  
cirílicos, griegos, kanji, etc) como identificadores Python.

Motivación
==========

Mucha gente en el mundo que escribe código Python no está familiarizada  
con la lengua inglesa, ni incluso conoce bien el sistema de escritura  
latino. Tales desarrolladores a menudo desean definir clases y funciones  
con nombres en sus lenguas nativas, antes que tener que usar una  
traducción al ingles (a menudo incorrecta) del concepto que desean nombrar.

Para algunos idiomas, existen sistemas de transliteración comunes (en  
particular, para los sistemas de escritura basados en el alfabeto latino).  
En otros idiomas, los usuarios tienen mayores dificultadas al usar el  
alfabeto latino para escribir sus palabras nativas.

Objeciones comunes
==================

Algunas objeciones se invocan a menudo en contra de propuestas similares a  
ésta.

La gente afirma que no serán capaces de usar una librería si para ello  
tienen que usar caracteres que no se pueden escribir con su teclado. Sin  
embargo, es el diseñador de la librería quien decide las restricciones de  
uso de la misma: la gente podría no tener acceso al código fuente (porque  
no esta publicado), o porque la licencia prohibe su uso, o porque la  
documentación esta en un lenguaje que no comprenden. Un desarrollador que  
desea hacer su librería ampliamente disponible debe hacer cierto número de  
elecciones explicitas (publicación, licenciamiento, lenguaje de la  
documentación, lenguaje de los identificadores). Es una elección que debe  
hacer el autor de la librería, no los diseñadores del lenguaje.

En particular, los proyectos que deseen ser de uso amplio probablemente  
deseen establecer una política donde todos los identificadores,  
comentarios y documentación se escriban en inglés (ej: la guia de estilo  
de código GNU).
Restringiendo el lenguaje a identificadores ASCII únicamente, no se  
garantizan comentarios y documentación en inglés, ni que los  
identificadores sean realmente palabras inglesas, así que una política  
adicional siempre es necesaria.

Especificación de Cambios en el Lenguaje
========================================

La sintaxis de los identificadores en Python estará basada en el Anexo  
UAX-31 [1]_ del estándar Unicode, con la elaboración y comentarios  
siguientes:

Dentro del rango ASCII (U+0001..U+007F), los caracteres válidos para  
identificadores son los mismos que en Python 2.5. En esta especificación  
solo se introducen caracteres adicionales fuera del rango ASCII. Para los  
otros caracteres, la clasificación se basa en la versión de Unicode  
Character Database incluida en el modulo ``unicodedata``.

La sintaxis de un identificador es ``<ID_Start> <ID_Continue>*``.

``ID_Start`` se define como todos los caracteres que tengan alguna de  
estas categorías generales: letras mayúsculas (Lu), letras minúsculas  
(Ll), letras de título (Lt), letras modificadoras (Lm), otras letras (Lo),  
letras numéricas (Nl, más el carácter de subrayado (XXX qué son las  
"stability extensions" listadas en UAX 31) [nota presente en el original  
en inglés].

``ID_Continue`` se define como todos los caracteres en ``ID_Start``, más  
marcas no espaciadoras (Mn), marcas de combinación de espacio (Mc),  
números decimales (Nd) y puntuaciones conectivas (Pc).

Todos los identificadores se convierten en la forma normal NFC mientras se  
parsean; la comparación de identificadores se basa en NFC.

Especificación de la Política
=============================

Como adición al Estilo de Codificación en Python, se prescribe la  
siguiente política: Todos los identificadores en la librería estándar de  
Python DEBEN usar identificadores sólo ASCII (sic), y DEBERÍAN usar  
palabras inglesas siempre que sea posible.

Como una opción, esta especificación puede ser aplicada a Python 2.x. En  
ese caso, los identificadores sólo ASCII continuarían siendo representados  
como strings de bytes en los diccionarios de los espacios de nombres; los  
identificadores con caracteres no-ASCII serían representados como strings  
Unicode.

Implementación
==============

Los siguientes cambios deberán hacerse al parser:

1. Si un carácter no ASCII se encuentra en la representación en UTF-8 del  
código fuente, se hace una búsqueda hacia adelante hasta encontrar el  
primer carácter ASCII no-identificador (ej: un espacio o carácter de  
puntuación).

2. La string completa UTF-8 se pasa a una función para normalizar la  
string en NFC, y entonces verificar que sigue la sintaxis de  
identificadores. Tal llamada no se hace para identificadores ASCII puros,  
que continúan siendo parseados de la misma forma que hasta ahora.

3. Si esta especificación se implementa en 2.x, se debe verificar que las  
librerías de reflexión (como pydoc) continúan funcionando cuando strings  
Unicode aparecen en los slots ``__dict__`` como claves.

Referencias
===========

.. [1] http://www.unicode.org/reports/tr31/

Copyright
=========

Este documento se pone en el dominio publico.
=== 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?

(El resumen de como viene la discusion hasta ahora se los debo - es tarde  
ya :) )

-- 
Gabriel Genellina




Más información sobre la lista de distribución Python-es