Identificadores No-Ascii en Python

[Gabriel Genellina]

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 <***@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 :) )

[Mariano Draghi]

Post by Gabriel Genellina
Hola
(Crossposteado en gmane.org.user-groups.python.argentina y
gmane.comp.python.general.castellano)
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,

[...]

Por muy loable, entendible que me resulta esto de fomentar otros
idiomas, me parece que un lenguaje de programación no es el ámbito
correcto.

Con el mismo criterio, alguien podría venir y armar un PEP para tener
una versión de Python en su propio lenguaje, y tendríamos entonces
abortos de la naturaleza como esos intentos fallidos de "traducir"
Delphi o algunas versiones de Basic, por ejemplo.

Si mañana agarro un .py que tiene caracteres en Kanji, tengo un
problema: Porque no tengo ni puta idea de como ingresar esos caracteres,
y para hacerlo, necesito software adicional, y saber usarlo. Y saber
distinguir entre 200 ideogramas que para mi ojo no entrenado se ven
iguales.

Es cierto que si el programador decide darle difusión a su librería,
entonces decidirá hacerla en inglés... pero... y si no se da cuenta de
entrada de su potencial? Acaso se va a tomar el laburo de renombrar todo
después? Proyectos FAMOSISIMOS hoy como Django y Trac, que nacieron como
una aplicación interna de una empresa, ¿tendrían la difusión que hoy
tienen, si estuvieran escritos y documentados en alemán, o español,
japonés, o el lenguaje que sea?

El alfabeto occidental "base", en cambio, está mucho más difundido, y
todos los que usan otro tipo de escritura, están acostumbrados a los
símbolos y a los métodos de entrada.

Creo que la internacionalización y la accesibilidad son un problema de
la interfaz, no del código. Y ahí (en la interfaz) es donde el
programador tiene que usar las herramientas correctas para asegurar que
sea fácil traducirlo a otros idiomas, visualizarlo en sistemas de
escritura diferentes (de derecha a izquierda, vertical, etc).

Pero el código... es el código. Cualquiera que hoy quiera tener acceso a
la documentación completa / reciente de las herramientas, tiene que de
todos modos --nos guste o no-- recurrir al inglés.

Si yo escribo:
class charango(object):

... mucha gente no lo va a entender, pero lo va a poder ingresar.

Ahora, comparemos:
class ñandú(object):
vs
class niandu(LucioTorre): # no pun intended... :p

Al que no sepa castellano, le resulta igual de indescifrable cualquiera
de las dos, solo que con la primera le compliqué la vida para tipearlo
(eh? y como meto ese cosito arriba de la "n"? ú es lo mismo que ù? (y
más de un hispanohablante de nuestra querida madre patria probablemente
no tenga la más pálida idea que significa ñandú, a pesar de ser
castellano...)

Cuando pasamos a otros sistemas de escritura, es peor:
class kungfu(object):
vs
class gongfu(object):
vs
class gōngfu(object):
vs
class 功夫(object):

El primero es la occidentalización de la fonética, el segundo es una
(simplificación) de la occidentalización en pinyin, el tercero es como
realmente se escribe fonéticamente en pinyin, y el cuarto, es lo mismo
en chino. Para poder tipear los dos últimos, en realidad tuve que ir a
la Wikipedia, buscar kungfu, copiar, pegar. Reeeeeee productivo.

Los dos primeros cualquiera los puede tipear, aún sin saber que está
escribiendo "destreza obtenida mediante el trabajo duro y el
esfuerzo" (o algo así). El 3ro y (sobretodo) el 4to, son una patada en
el culo para cualquiera que no sepa (algo de) chino.

No.

Definitivamente no me gusta la propuesta de esa PEP, y me parece que si
de meter mano el parser se trata, hay muchos otros features que me
gustaría ver implementados / mejorados en el lenguaje antes que la
posibilidad de expresarme como si fuera José Hernández a la hora de
escribir un programa.

[alejandro weil]

Buenas!

Post by Mariano Draghi

Post by Gabriel Genellina
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,

[...]
Por muy loable, entendible que me resulta esto de fomentar otros
idiomas, me parece que un lenguaje de programación no es el ámbito
correcto.
Con el mismo criterio, alguien podría venir y armar un PEP para tener
una versión de Python en su propio lenguaje, y tendríamos entonces
abortos de la naturaleza como esos intentos fallidos de "traducir"
Delphi o algunas versiones de Basic, por ejemplo.

A mi me parece que querer exclusividad occidental es una chotada..
porque por ejemplo, maniana un chinito hace un lenguaje re bueno y me
gustaria poder usarlo con caracteres occidentales y no que me diga, se
penso asi y ya.

Igualmente, asi como tener identificadores en cualquier lenguaje me
parece perfecto, tener que los keywords etc del python en otro idioma
no me molesta. Esto ultimo no me parece super importante, pero
tambien, que se puedan cambiar, me parece muy sencillo porque la
conversion de uno a otro se puede hacer automaticamente, entonces, si
lo pueden hacer, mejor!

Post by Mariano Draghi
Si mañana agarro un .py que tiene caracteres en Kanji, tengo un
problema: Porque no tengo ni puta idea de como ingresar esos caracteres,
y para hacerlo, necesito software adicional, y saber usarlo. Y saber
distinguir entre 200 ideogramas que para mi ojo no entrenado se ven
iguales.

Bueno, pero eso es un problema de las herramientas mas que de el idioma.
Por que?
Porque lo pienso asi. Los refactoring-browsers te dejan buscar los
usos de un identificador determinado, no deberias ni tener que
tipearlo, solamente lo marcas con el mouse, y podrias tambien
renamearlo (en todos los lugares que se use).

E incluso, hacer eso mismo n veces para que pase todo a algo "ascii",
automaticamente.
Y si, perdes de saber cual fue el nombre que el programador le puso y
por que, o para que lo piensa usar. Pero ese problema existe siempre,
si no sabes el lenguaje del programador. :-)

Saludos!
tenuki

[Lucio Torre]

Post by alejandro weil
E incluso, hacer eso mismo n veces para que pase todo a algo "ascii",
automaticamente.
Y si, perdes de saber cual fue el nombre que el programador le puso y
por que, o para que lo piensa usar. Pero ese problema existe siempre,
si no sabes el lenguaje del programador. :-)

Este tema les recuerdo lo que se comento en la ultima reunion, que es
algo que les preocupa mucho a los creadores de la OLPC. Si un chico en
salta tiene una notebook con un boton "ver codigo fuente" y para
entenderlo antes que python tiene que aprender ingles, es un problema mas.

Asi que sin duda es un tema interesante pero creo que la solucion es mas
grande que solo soportar unicode. <futurologia barata> creo que
eventualmente el codigo va a dejar de ser texto para ser estructuras mas
complejas para que todo esto se pueda hacer on the fly</futurologia barata>

[alejandro weil]

Post by Lucio Torre

Post by alejandro weil
E incluso, hacer eso mismo n veces para que pase todo a algo "ascii",
automaticamente.
Y si, perdes de saber cual fue el nombre que el programador le puso y
por que, o para que lo piensa usar. Pero ese problema existe siempre,
si no sabes el lenguaje del programador. :-)

Este tema les recuerdo lo que se comento en la ultima reunion, que es
algo que les preocupa mucho a los creadores de la OLPC. Si un chico en
salta tiene una notebook con un boton "ver codigo fuente" y para
entenderlo antes que python tiene que aprender ingles, es un problema mas.

Si, creo que lo de los identificadores debe estar MUY motivado por eso
que decis.

Post by Lucio Torre
Asi que sin duda es un tema interesante pero creo que la solucion es mas
grande que solo soportar unicode. <futurologia barata> creo que
eventualmente el codigo va a dejar de ser texto para ser estructuras mas
complejas para que todo esto se pueda hacer on the fly</futurologia barata>

No puedo dejarte pasar sin pedir explicaciones a que te referis con on
the fly. ;-)

Igual yo pienso algo parecido, pero creo que en el fondo el usuario
(programador) siempre va a necesitar identificadores.
Pero por ahi, los keyboards del lenguaje pueden desaparecer, claro esta.

salud!

[Pablo Ziliani]

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

Acá debió decir pyar-***@public.gmane.org y python-es-***@public.gmane.org
Pensé que habían forkeado la lista...

Post by Gabriel Genellina
PEP: 3131
(...)
Aca va un intento de traducción - hice lo mejor que pude...

Gabriel,

Más allá de sentirme personalmente más cerca del pensamiento de Mariano,
me gustaría saber si en el futuro pensás o te gustraría seguir
traduciendo recursos de Python. Porque si va a ser así, quizás quieras
unirte a algún proyecto de traducción[1] (se ha hablado mucho sobre esto
en reuniones y hay más de un interesado), y de esa manera evitar que tu
trabajo quede en la nada (o en los archivos de gmane/grulic). Luego en
la lista se podría discutir el PEP más en detalle (para lo cual está
bueno contar con el recurso traducido). Es decir, en la lista se podría
hacer el anuncio y la discusión, pero el recurso quedaría guardado
externamente. Obviamente, esto es sólo una sugerencia.

Saludos,
Pablo

[1] ej.: http://pyspanishdoc.sourceforge.net/

[Ariel Rodriguez]

Bueno, soy muy nuevo en la lista, y bastante nuevo en Python también
(la presentación va más abajo), pero me llamó la atención la mención
de proyectos de traducir, y quisiera saber más al respecto. Debo
decir que yo también estoy más cerca de los argumentos de Mariano,
creo que si es interesante traducir la documentación y creo que los
identificadores están bien en ASCII.
Ahora pasamos a la parte "Hola mundo, soy un nerd", :) a la que me
venía resistiendo, pero ya que estoy participando de la discusión, me
parece que el resto tiene derecho a saber quien soy.
Mi nombre es Ariel Rodriguez, estudie en Exactas de la UBA
Computación y Matemática (todavía debo 2 materias de matemática, pero
no le avisen a mi vieja :) ) y después me doctoré en la Universidad
de Edinburgh (UK). Desde hace muuuuchoooo tiempo trabajo programando
para Mac, desde los viejos tiempos de las toolbox en Pascal, y desde
hace algunos años (cuatro o cinco) también trabajo en programación
Web. Con Python voy y vengo desde fines de los 90. La verdad es que
nunca hice nada serio con Python hasta el momento (pero tengo muchas
ganas) y de tanto en tanto agarro algún libro nuevo y hago prolijito
todos los ejercicios. La última vuelta a Python fue hace un mes, más
o menos. Como dije, trabajo bastante en programación Web, y como PHP
mucho no me gusta, y todo el alboroto en torno a Ruby on Rails me
suena a marketing (no me tomen a mal, Rails realmente me parece un
framework piola, hice un par de aplicaciones Web y la verdad es que
es interesante, pero no termino de tomarle el gustito a Ruby) me puse
a buscar y estoy jugando con Django desde hace un tiempito (todavía
tengo que probarlo en un entorno real, pero me gusta, y Python me
gusta más que Ruby).
Espero no haber aburrido. Un saludo para todos.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

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

Pensé que habà an forkeado la lista...

Post by Gabriel Genellina
PEP: 3131
(...)
Aca va un intento de traducción - hice lo mejor que pude...

Gabriel,
Más allá de sentirme personalmente más cerca del pensamiento de
Mariano, me gustarà a saber si en el futuro pensás o te gustrarà a
seguir traduciendo recursos de Python. Porque si va a ser asà ,
quizás quieras unirte a algún proyecto de traducción[1] (se ha
hablado mucho sobre esto en reuniones y hay más de un interesado),
y de esa manera evitar que tu trabajo quede en la nada (o en los
archivos de gmane/grulic). Luego en la lista se podrà a discutir el
PEP más en detalle (para lo cual está bueno contar con el recurso
traducido). Es decir, en la lista se podrà a hacer el anuncio y la
discusión, pero el recurso quedarà a guardado externamente.
Obviamente, esto es sólo una sugerencia.
Saludos,
Pablo
[1] ej.: http://pyspanishdoc.sourceforge.net/
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Facundo Batista]

Post by Ariel Rodriguez
Ahora pasamos a la parte "Hola mundo, soy un nerd", :) a la que me

Bienvenido.

Post by Ariel Rodriguez
Mi nombre es Ariel Rodriguez, estudie en Exactas de la UBA
Computación y Matemática (todavía debo 2 materias de matemática, pero
no le avisen a mi vieja :) ) y después me doctoré en la Universidad
de Edinburgh (UK). Desde hace muuuuchoooo tiempo trabajo programando

No le aviso a nadie, ¿pero cómo te doctoraste en una Universidad
extranjera sin haber terminado la carrera acá?

BTW, ¿cómo sabés que tu vieja no está suscripta a esta lista? ;)

Slds.

[Ariel Rodriguez]

Gracias por la bienvenida.
Me expresé mal. De la carrera que debo dos materias es de la
licenciatura en matemática (que prometo terminar en algún momento).
La licenciatura en ciencias de la computación la termine en la UBA.
Disculpas por las confusiones.
Y la verdad es que no me la imagino a mi vieja en una lista de
correo. Gracias que acepto que le regalara una compu para mandar
mails :)
Una vez más gracias por la bienvenida.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

Post by Facundo Batista

Post by Ariel Rodriguez
Ahora pasamos a la parte "Hola mundo, soy un nerd", :) a la que me

Bienvenido.

Post by Ariel Rodriguez
Mi nombre es Ariel Rodriguez, estudie en Exactas de la UBA
Computación y Matemática (todavía debo 2 materias de matemática, pero
no le avisen a mi vieja :) ) y después me doctoré en la Universidad
de Edinburgh (UK). Desde hace muuuuchoooo tiempo trabajo programando

No le aviso a nadie, ¿pero cómo te doctoraste en una Universidad
extranjera sin haber terminado la carrera acá?
BTW, ¿cómo sabés que tu vieja no está suscripta a esta lista? ;)
Slds.
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Sebastian Bassi]

Y la verdad es que no me la imagino a mi vieja en una lista de correo. Gracias que acepto que le regalara una compu para mandar mails :)

En estos casos está bueno el "***@il", un aparejo de Telefonica que
se consigue por 60$ en MercadoLibre, solo trae para mandar mail y no
hay que lidiar con el SO ni con nada "extra". Lastima que

[Gabriel Genellina]

En Tue, 15 May 2007 13:25:32 -0300, Pablo Ziliani

Post by Pablo Ziliani

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

Pensé que habían forkeado la lista...

Son lo mismo; los de arriba son los newsgroups "espejos" de las dos
listas. Yo prefiero usar los newsgroups, no las listas.

Post by Pablo Ziliani
Más allá de sentirme personalmente más cerca del pensamiento de Mariano,
me gustaría saber si en el futuro pensás o te gustraría seguir
traduciendo recursos de Python. Porque si va a ser así, quizás quieras
unirte a algún proyecto de traducción[1] (se ha hablado mucho sobre esto
en reuniones y hay más de un interesado), y de esa manera evitar que tu
trabajo quede en la nada (o en los archivos de gmane/grulic). Luego en

Si, puede ser. El problema con las traducciones es mantenerlas
actualizadas - hay que buscar algun mecanismo que permita hacerlo mas o
menos facil, o buscar las diferencias entre versiones, o algun mecanismo
de notificacion de cambios...
Por ejemplo, supongamos que quiero actualizar la traducción de la libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano, con esta
última editable directamente para aplicarle los cambios.
Y despues, hacer lo mismo para cuando salga la 2.5.2, y la 2.6...
Tal vez pido mucho, pero, existe tal herramienta? (KDiff3
http://kdiff3.sourceforge.net/ hace algo de eso pero no alcanza)

[alejandro weil]

Hola!

On 5/16/07, Gabriel Genellina <gagsl-py2-/***@public.gmane.org> wrote:
[..]

Post by Gabriel Genellina
Por ejemplo, supongamos que quiero actualizar la traducción de la libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano, con esta
última editable directamente para aplicarle los cambios.

Algo así queríamos hacer y pensamos un poco en un sprint que hicimos.
Creo que la idea en la que teniamos (o al menos yo) mas esperanzas era algo así:
Lo pensabamos montado en un moinmoin.
Todo el texto, estaba partido por parrafos en cada uno de los textos
de documentación.
Y tenias que traducir atomicamente por parrafo.

Cuando salia una nueva version.
Lo que se hacia era, generar las diferencias de los parrafos en
ingles, y marcar esos como a traducir.

Y estarian juntos, en ambas versiones, la nueva y la vieja, las
versiones traducidas en ingles y en castellano (no me acuerdo como era
esto, si una version abajo de la otra o un parrafo abajo del otro o
que)..

Me parecia que estaba bueno hacerlo sobre un wiki.. pero bueno.. quedo
medio en el tintero.

Gillo, había hecho ya cosas para pasar la documentación que estaba en
latex al formato del wiki de moinmoin.

Después nos parecio que en realidad no tenia mucho sentido hacer ese
camino que tendría alguna pérdida de información y probamos un poco
las siguientes alternativas:

1. usar un componente (no me acuerdo como se llama) que le instalas al
moin y que es algo asi como latex2bmp, y entonces vos le pones en el
source de la pagina, en lugar de wiki formating un texto en latex, y
el tipo, cuando tiene que mostrar dicha pagina, llama a latex genera
el dvi imagino y de ahí una imagen y el server te manda un html con la
imagen (o con las formulas en imagenes, creo que no procesaba todo el
texto sino que vos le indicabas que lo hiciera para algunas cosas
solamente en la pagina, pero bueno no estoy seguro).

2. la otra opcion era, armar un nuevo ?codigo? (tampoco me acuerdo
exactamente como los llamaba moin) que el moin supiera interpretar,
como un nuevo lenguaje interno (pero ojo, moin viene preparado como
para hacerle estas cosas), y hacer que entienda TeX. No es muy dificil
y había algo mas o menos andando.. y aunque el output no iba a tener
las maravillosas cosas del output en imagenes, la documentación
quedaba realmente muy parecida a lo que era la original.

Bueno, eso es todo lo que recuerdo.
Ideas?

[Gabriel Genellina]

En Thu, 17 May 2007 00:52:30 -0300, alejandro weil

Post by alejandro weil

Post by Gabriel Genellina
Por ejemplo, supongamos que quiero actualizar la traducción de la libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano, con esta
última editable directamente para aplicarle los cambios.

Algo así queríamos hacer y pensamos un poco en un sprint que hicimos.
Lo pensabamos montado en un moinmoin.
Todo el texto, estaba partido por parrafos en cada uno de los textos
de documentación.
Y tenias que traducir atomicamente por parrafo.

Parece razonable.

Post by alejandro weil
Gillo, había hecho ya cosas para pasar la documentación que estaba en
latex al formato del wiki de moinmoin.
Después nos parecio que en realidad no tenia mucho sentido hacer ese
camino que tendría alguna pérdida de información y probamos un poco

Nop, a mi tampoco me gusta, dejandolo como Latex podes usar todas las
herramientas originales para generar la documentacion (en html, en pdf, en
chm... deberia salir todo igualito pero con los textos en castellano :) )

Post by alejandro weil
1. usar un componente (no me acuerdo como se llama) que le instalas al
moin y que es algo asi como latex2bmp, y entonces vos le pones en el
2. la otra opcion era, armar un nuevo ?codigo? (tampoco me acuerdo
exactamente como los llamaba moin) que el moin supiera interpretar,
como un nuevo lenguaje interno (pero ojo, moin viene preparado como

A esto no le veo mucho sentido. Yo usaria el moinmoin solo como interfase
visual, manteniendo las marcas en latex. Por lo general ni siquiera hay
que tocar el markup - los nombres de variables, de funciones, de
argumentos etc. se mantienen igual en castellano. Por poner un ejemplo:

\begin{funcdesc}{rename}{src, dst}
Rename the file or directory \var{src} to \var{dst}. If \var{dst} is
a directory, \exception{OSError} will be raised. On \UNIX, if
\var{dst} exists and is a file, it will be removed silently if the
user has permission.
Availability: Macintosh, \UNIX, Windows.
\end{funcdesc}

En la traduccion todos esos \begin{funcdesc}{rename}, \var(src),
\exception{OSError} se mantienen igual; lo unico que hay que tocar es el
texto. A lo sumo se pone un poco molesto cuando cambia el orden de la
frase en castellano, y hay que andar moviendo las cosas de lugar.

Es decir, el resultado de la traduccion sería un documento latex tambien -
con el mismo markup, estilos, definiciones que el original, solo que con
el contenido traducido. En base al latex se generan todos los demas
formatos que quieras.

[Facundo Batista]

Post by alejandro weil
Cuando salia una nueva version.
Lo que se hacia era, generar las diferencias de los parrafos en
ingles, y marcar esos como a traducir.
Y estarian juntos, en ambas versiones, la nueva y la vieja, las
versiones traducidas en ingles y en castellano (no me acuerdo como era
esto, si una version abajo de la otra o un parrafo abajo del otro o
que)..

Quizás haya otro camino, que sea más fácil.

No hace falta agarrar los docs de la 2.4, los docs de la 2.5, y empezar
a ver cómo se modificaron, tratando de sincronizar los cambios, para
ofrecerle al usuario qué modificar.

Podés agarrar directamente la info que te da SVN, y "mostrársela" al
usuario.

Tipo: "Este párrafo lo tenés que traducir, porque desde la última vez
que alguien lo tocó, estos cambios se le aplicaron al original" (tener
en cuenta de no mostrar acá los n cambios que se hicieron, sino un
collage de los mismos, dejando la versión más última de cada linea del
párrafo).

Slds.

[Ariel Rodriguez]

En líneas generales me parece que la idea es buena. Me gustaría
participar de la implementación.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

Post by alejandro weil
Hola!
[..]

Post by Gabriel Genellina
Por ejemplo, supongamos que quiero actualizar la traducción de la libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano, con esta
última editable directamente para aplicarle los cambios.

Algo así queríamos hacer y pensamos un poco en un sprint que hicimos.
Lo pensabamos montado en un moinmoin.
Todo el texto, estaba partido por parrafos en cada uno de los textos
de documentación.
Y tenias que traducir atomicamente por parrafo.
Cuando salia una nueva version.
Lo que se hacia era, generar las diferencias de los parrafos en
ingles, y marcar esos como a traducir.
Y estarian juntos, en ambas versiones, la nueva y la vieja, las
versiones traducidas en ingles y en castellano (no me acuerdo como era
esto, si una version abajo de la otra o un parrafo abajo del otro o
que)..
Me parecia que estaba bueno hacerlo sobre un wiki.. pero bueno.. quedo
medio en el tintero.
Gillo, había hecho ya cosas para pasar la documentación que estaba en
latex al formato del wiki de moinmoin.
Después nos parecio que en realidad no tenia mucho sentido hacer ese
camino que tendría alguna pérdida de información y probamos un poco
1. usar un componente (no me acuerdo como se llama) que le instalas al
moin y que es algo asi como latex2bmp, y entonces vos le pones en el
source de la pagina, en lugar de wiki formating un texto en latex, y
el tipo, cuando tiene que mostrar dicha pagina, llama a latex genera
el dvi imagino y de ahí una imagen y el server te manda un html con la
imagen (o con las formulas en imagenes, creo que no procesaba todo el
texto sino que vos le indicabas que lo hiciera para algunas cosas
solamente en la pagina, pero bueno no estoy seguro).
2. la otra opcion era, armar un nuevo ?codigo? (tampoco me acuerdo
exactamente como los llamaba moin) que el moin supiera interpretar,
como un nuevo lenguaje interno (pero ojo, moin viene preparado como
para hacerle estas cosas), y hacer que entienda TeX. No es muy dificil
y había algo mas o menos andando.. y aunque el output no iba a tener
las maravillosas cosas del output en imagenes, la documentación
quedaba realmente muy parecida a lo que era la original.
Bueno, eso es todo lo que recuerdo.
Ideas?
--
There is no dark side of the moon really. Matter of fact it's all dark.
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Daniel Nuske]

En líneas generales me parece que la idea es buena. Me gustaría participar de

la implementación.

Por ejemplo, supongamos que quiero actualizar la traducción de la libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano, con esta
última editable directamente para aplicarle los cambios.

hola mundo, soy Daniel Nuske, me salteo el paso de mandar mi script, ya muhcos
se burlaron de mi ^^

pero estoy en la lista desde hace unos días y me interesó este tema, quiero
compartir con ustedes un proyecto, que es bastante chico:

se trata de un traductor que usa la pagina del traductor de google, es un script
muy simple que lo que hace es parsear lo que devuelve la página.

aca está el código en la pagina del proyecto:
http://code.google.com/p/pytranslator/source

la idea es agregarle la lógica para que no intente traducir palabras reservadas
del lenguaje en una documentacion, pero que el resto lo muesrte traducido,

De paso forzamos a goo*** (¿se pueden decir marcas? ^^ ) a que mejore su
traductor que le falta mucha comprensión.

diganme qué les parece la idea... programar en vez de documentar... supongo que
la aceptación va a ser buena.

saludos! =)

Daniel Nuske

[Ariel Rodriguez]

El problema es que, por más que le cueste a Chomsky y sus gramáticas
generativas, el estado del arte de las traducciones automáticas deja
muchisimo que desear. Hoy por hoy, todo lo que pueden generar los
traductores automáticos es un texto que debe ser "revisado-traducido"
por un humano. Lo que es peor, el texto cocoliche es muchas veces más
difícil de traducir que el original. Y no es una limitación del
traductor de Google sino de la estructura misma de los lenguajes
naturales. Por eso me parece que lo mejor sería armar una especie de
SVN de documentación, que permita editar fácilmente los textos.
No sé cual es la opinión del resto.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

En là neas generales me parece que la idea es buena. Me gustarà a
participar de

la implementación.

Por ejemplo, supongamos que quiero actualizar la traducción de la
libreria
estandar, que aparentemente corresponde a la 2.0, para que refleje el
estado actual de la 2.5. Necesito una herramienta que me muestre las
diferencias entre la 2.0 y la 2.5 en inglés, y al mismo tiempo
sincronizada párrafo a párrafo con la version 2.0 en castellano,
con esta
última editable directamente para aplicarle los cambios.

hola mundo, soy Daniel Nuske, me salteo el paso de mandar mi
script, ya muhcos
se burlaron de mi ^^
pero estoy en la lista desde hace unos dà as y me interesó este
tema, quiero
se trata de un traductor que usa la pagina del traductor de google, es un script
muy simple que lo que hace es parsear lo que devuelve la página.
http://code.google.com/p/pytranslator/source
la idea es agregarle la lógica para que no intente traducir
palabras reservadas
del lenguaje en una documentacion, pero que el resto lo muesrte traducido,
De paso forzamos a goo*** (¿se pueden decir marcas? ^^ ) a que
mejore su
traductor que le falta mucha comprensión.
diganme qué les parece la idea... programar en vez de
documentar... supongo que
la aceptación va a ser buena.
saludos! =)
Daniel Nuske
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Facundo Batista]

Post by Ariel Rodriguez
El problema es que, por más que le cueste a Chomsky y sus gramáticas

¿A qué parte del mail anterior estás contestando? ¿Escuchaste hablar de
las des-ventajas del top-posting?

Post by Ariel Rodriguez
naturales. Por eso me parece que lo mejor sería armar una especie de
SVN de documentación, que permita editar fácilmente los textos.

¿Algo como esto?

http://pyspanishdoc.cvs.sourceforge.net/pyspanishdoc/Doc/Doc/

Slds.

[Gabriel Genellina]

En Tue, 15 May 2007 05:47:13 -0300, Gabriel Genellina

Post by Gabriel Genellina
PEP: 3131
Título: Soporte de Identificadores No-ASCII
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?

Un resumen de los argumentos que aparecieron:

- En castellano se necesitan pocas letras adicionales aparte de ASCII asi
que no hay una gran necesidad de usar Unicode en identificadores por parte
de los desarrolladores hispanoparlantes.

- Sería bueno si los nombres de atributos de clases se pudieran
corresponder directamente con los nombres de columna de tablas; tambien a
algunos les interesaría usar identificadores como la letra griega Pi en
fórmulas matemáticas.

- Python puede ser embebido y extendido usando librerías - en esos casos,
lo que prima es el uso específico del dominio de la aplicacion. Permitir
que el usuario final escriba sus scripts/tasklets/etc usando nombres y
lenguaje específicos del dominio es una gran cosa.

- Otros mostraron los mismos reparos ya dichos por otros anteriormente:
legibilidad del código fuente; ser incapaz de tipear identificadores;
riesgo de que los keywords sean traducidos tambien; no se puede conocer de
antemano si el codigo va a tener amplia difusion en el futuro asi que
mejor usar identificadores en ingles desde un principio.

- Alguien propuso usar algun tipo de secuencias de escape, soportadas por
plugins en el editor, de manera que no hay necesidad siquiera de modificar
el parser actual.

- Las herramientas de refactoring permiten renombrar identificadores
foráneos de manera que no es un verdadero problema.

[alejandro weil]

Post by Gabriel Genellina
En Tue, 15 May 2007 05:47:13 -0300, Gabriel Genellina

Post by Gabriel Genellina
PEP: 3131
Título: Soporte de Identificadores No-ASCII

[..]

Post by Gabriel Genellina
- Las herramientas de refactoring permiten renombrar identificadores
foráneos de manera que no es un verdadero problema.

Lo que quise decir es que, ya que no sé realmente si hay herramientas
de refactoring que lo permitan para python, es que el problema,
deberia verse en el contexto de las herramientas disponibles, mas que
en el de el lenguaje en sí.

No creo que haya que acotar el lenguaje porque una herramienta no esta
disponible, sino al contrario.

Por las dudas, preferí aclararlo. :-)

Y también, que al ser fijos los keywords la traducción de los mismos
no deberia ser un problema porque se podria hacer tranquilamente de
manera automatica (suponiendo que se dispone de charsets adecuados
para traducirlos a cualquier lenguaje) (Y entonces cualquiera puede
leer cualquier código python con keywords en cualquier idioma,
nuevamente porque las herramientas deberían dejar elegir el idioma en
que verías los keywords). Y alguna otra pavada mas por ahí..

Hasta luego!

[Gabriel Genellina]

En Thu, 17 May 2007 00:37:19 -0300, alejandro weil

Post by alejandro weil
On 5/16/07, Gabriel Genellina

Post by Gabriel Genellina
- Las herramientas de refactoring permiten renombrar identificadores
foráneos de manera que no es un verdadero problema.

Lo que quise decir es que, ya que no sé realmente si hay herramientas
de refactoring que lo permitan para python, es que el problema,
deberia verse en el contexto de las herramientas disponibles, mas que
en el de el lenguaje en sí.
No creo que haya que acotar el lenguaje porque una herramienta no esta
disponible, sino al contrario.

El problema con Python es que los identificadores no se declaran, los
tipos de los argumentos tampoco, y encima se pueden usar variables para
referenciar atributos.
En un lenguaje estático (como Java, Delphi, C++...) es facil, incluso no
necesitas ninguna herramienta: le cambias el nombre en la declaracion de
un atributo y dejas que el compilador te tire todos los errores :)
En Python es mas dificil: si una clase Login tiene un atributo llamado
"user", y queres que ahora se llame "username", no alcanza con buscar
todos los .user que aparecen (como sabes, o mas bien, como sabe la
herramienta que lo que esta a la izquierda del punto es siempre una
instancia de Login?), y aun si reemplazas todos, te quedan los usos de
getattr(...,nombre) donde nombre es una variable que vaya a saber uno de
donde proviene...
En fin, BicycleRepairMan trataba de hacerlo, pero no siempre le salia bien.

Post by alejandro weil
Por las dudas, preferí aclararlo. :-)

Ok!

Post by alejandro weil
Y también, que al ser fijos los keywords la traducción de los mismos
no deberia ser un problema porque se podria hacer tranquilamente de
manera automatica (suponiendo que se dispone de charsets adecuados
para traducirlos a cualquier lenguaje) (Y entonces cualquiera puede
leer cualquier código python con keywords en cualquier idioma,
nuevamente porque las herramientas deberían dejar elegir el idioma en
que verías los keywords). Y alguna otra pavada mas por ahí..

Lo de traducir los keywords no creo que nunca se acepte... bueno, tanto
como nunca no sé, pero al menos no antes de que Guido muera...
Como alguien comentó por ahi, incluso para los chicos chinos que no saben
nada de inglés, los keywords no representan el problema - son apenas una
docena de palabras y nada mas, se los ve como simbolos y punto. El real
problema es que no pueden escribir nombres de variables con sentido.

[alejandro weil]

Buenas!

Post by Gabriel Genellina

Post by alejandro weil
Lo que quise decir es que, ya que no sé realmente si hay herramientas
de refactoring que lo permitan para python, es que el problema,
deberia verse en el contexto de las herramientas disponibles, mas que
en el de el lenguaje en sí.
No creo que haya que acotar el lenguaje porque una herramienta no esta
disponible, sino al contrario.

El problema con Python es que los identificadores no se declaran, los
tipos de los argumentos tampoco, y encima se pueden usar variables para
referenciar atributos.

Si.. es terrible.

Post by Gabriel Genellina
En un lenguaje estático (como Java, Delphi, C++...) es facil, incluso no
necesitas ninguna herramienta: le cambias el nombre en la declaracion de
un atributo y dejas que el compilador te tire todos los errores :)

Claro, ahí es facilisimo, estamos de acuerdo!

Post by Gabriel Genellina
En Python es mas dificil: si una clase Login tiene un atributo llamado
"user", y queres que ahora se llame "username", no alcanza con buscar
todos los .user que aparecen (como sabes, o mas bien, como sabe la
herramienta que lo que esta a la izquierda del punto es siempre una
instancia de Login?), y aun si reemplazas todos, te quedan los usos de
getattr(...,nombre) donde nombre es una variable que vaya a saber uno de
donde proviene...

Si, ese es el problema.
Tarde, entre otras cosas, porque quería ver como funcionaba en
Smalltalk el famoso RefactoringBrowser.. pero bueno.. una de las cosas
que me recordaron de Smalltalk (sí.. lamentablemente lo tengo muy
oxidado), es que las variables de instancia NO se pueden acceder de
afuera directamente, sino que hay que hacer accesors, eso te evita el
problema que ahi describís, sin embargo, el mismo problema deberia
ocurrir cuando se llaman los métodos de un objeto, vos tenés el objeto
y a priori no sabés de que clase es, asi que a lo sumo podrías decir
que es de alguna de las clases que implementa dicho método.. lo cual
por ahí es suficiente pero no siempre.
¿alguien sabe mas al respecto??

Post by Gabriel Genellina

Post by alejandro weil
Y también, que al ser fijos los keywords la traducción de los mismos
no deberia ser un problema porque se podria hacer tranquilamente de
manera automatica (suponiendo que se dispone de charsets adecuados
para traducirlos a cualquier lenguaje) (Y entonces cualquiera puede
leer cualquier código python con keywords en cualquier idioma,
nuevamente porque las herramientas deberían dejar elegir el idioma en
que verías los keywords). Y alguna otra pavada mas por ahí..

Lo de traducir los keywords no creo que nunca se acepte... bueno, tanto
como nunca no sé, pero al menos no antes de que Guido muera...
Como alguien comentó por ahi, incluso para los chicos chinos que no saben
nada de inglés, los keywords no representan el problema - son apenas una
docena de palabras y nada mas, se los ve como simbolos y punto. El real
problema es que no pueden escribir nombres de variables con sentido.

Totalmente de acuerdo.
En realidad, no creo que se necesite plantear que se generen en otro
idioma, ni es necesario.

Post by Gabriel Genellina
--
Gabriel Genellina
PD: Vos no sos un ex fidonético?

claro!

Saludos,
first pueblito point 4:901/225.1 /250 (si la memoria no me falla)

[Gabriel Genellina]

En Sun, 20 May 2007 17:54:41 -0300, alejandro weil

Post by alejandro weil

Post by Gabriel Genellina
PD: Vos no sos un ex fidonético?

claro!
Saludos,
first pueblito point 4:901/225.1 /250 (si la memoria no me falla)

4:900/214.11 creo - en el nodo de Bugland.
Suficiente offtopic por hoy - y se me pianta un lagrimón :~(

[Lucio Torre]

Post by Gabriel Genellina

Post by Pablo Ziliani
Saludos,
first pueblito point 4:901/225.1 /250 (si la memoria no me falla)

4:900/214.11 creo - en el nodo de Bugland.
Suficiente offtopic por hoy - y se me pianta un lagrimón :~(

Gabriel,

Bugland no era uno de los primeros (si no el unico) bbs dedicado a la
programacion en C? Como se llamaba el sysop?

Lucio.

[Mi Reflejo]

El sysop se llama Daniel Mastraccio. Alias mastra, alias DM.

Y si, era de programacion. Duró hasta 2000 y pico.

Saludos,
--
Martín Conte Mac Donell
http://www.catartico.com

Post by Pablo Ziliani

Post by Gabriel Genellina

Post by Pablo Ziliani
Saludos,
first pueblito point 4:901/225.1 /250 (si la memoria no me falla)

4:900/214.11 creo - en el nodo de Bugland.
Suficiente offtopic por hoy - y se me pianta un lagrimón :~(

Gabriel,
Bugland no era uno de los primeros (si no el unico) bbs dedicado a la
programacion en C? Como se llamaba el sysop?
Lucio.
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Gabriel Genellina]

En Tue, 22 May 2007 11:44:37 -0300, Lucio Torre

Post by Pablo Ziliani

Post by Gabriel Genellina

Post by Pablo Ziliani
Saludos,
first pueblito point 4:901/225.1 /250 (si la memoria no me falla)

4:900/214.11 creo - en el nodo de Bugland.
Suficiente offtopic por hoy - y se me pianta un lagrimón :~(

Gabriel,
Bugland no era uno de los primeros (si no el unico) bbs dedicado a la
programacion en C? Como se llamaba el sysop?

Si. El sysop era Daniel Mastracchio, el que hizo el logo argentino de Fido
(no el logo original del perrito con diskette, era otro perrito).

[Sebastian Bassi]

Post by Gabriel Genellina
PEP: 3131

Flor de quilombo se armó con eso. A nosotros casi no nos afecta porque
son pocos caracteres de diferencia entre ASCII y "castellano". Pero me
imagino que bueno seria para un chino o un ruso poder poner variables
con los nombres que quieren. No puedo entender todavia porque hay
gente que le molesta. ¿Porque no puede leer tai? Y bueno, que se joda
el tailandes por hacer codigo que no pueda compartir, pero ¿porque
molestarme si un tailandes/japones/arabe/frances quiere hacer codigo
que él pueda leer facilmente? ¿Que le afecta a los que se oponen?

[Ariel Rodriguez]

Yo creo entender que para muchos no es tanto una cuestión de molestia
como de practicidad, y porque no decirlo, de conservadurismo (en el
sentido de que "si no está roto para que arreglarlo", no se enojen
conmigo :) ). A ver si me puedo explicar un poco mejor. Hoy por hoy,
el inglés es la lingua franca de la programación, y lo ha sido desde
los albores de la ciencia de la computación. Muchos tenemos adentro
de la cabeza la necesidad de compartir el código que escribimos, que
la mejor forma de escribir un programa es pensando que otro lo va a
leer. Y si otro lo va a leer y la lingua franca de facto es el
inglés, muchos optamos por usar nombres en inglés para
identificadores de programas que sabemos que solo son para nosotros.
No por tilingos, sino por costumbre. Se me dirá que la razón
programadores cuyo idioma natal es inglés / programadores cuyo idioma
natal NO es inglés es cada vez menor y es cierto, así como también
es cierto que quizá en un futuro no muy lejano todos estemos
programando en mandarín. Lo que digo es que hoy muchos estamos más
acostumbrados a leer código en inglés. Ya no recuerdo quien apuntó
que uno de los factores que había contribuido al éxito de
aplicaciones populares en Python (y en cualquier otro lenguaje) era
una buena documentación escrita en inglés. Creo que es un punto a
tomar en cuenta. ¿Cuántos de nosotros sabríamos algo de Django, por
poner un ejemplo popular en estos días, si hubiera nacido en un
diario de Nepal en lugar de en uno de Kansas? En el fondo yo creo que
hoy por hoy, para compartir código el inglés es la mejor opción.
Dicho esto, me gustaría agregar que siendo Python (como cualquier
otro lenguaje de programación) un leguaje formal, Mientras no
modifiquemos la gramática o la sintaxis, el lenguaje no pierde su
formalidad. Poco importa si el nombre de un identificador está
escrito en cirílico o plain vanilla ASCII. Aún cuando no sé
mandarin, si el día de mañana me toca leer un programa con
caracteres chinos, voy a poder entenderlo igual porque la gramática y
la sintaxis subyacentes serían las mismas y solo debería leer los
identificadores como lo que son, una cadena de caracteres que
determina univocamente una porción determinada del programa. Qué yo
pueda o no decodificar semánticamente esa cadena de caracteres pasa a
segundo plano. Y si, hay algo de la Chinese Room de Searle en todo
esto. Ahora bien, ya que estamos en el tema, la sintaxis y la
gramática de los lenguajes formales está basada (sobre todo en los
altos como Python) en lenguajes naturales. En particular, mucho de la
gramática y de la sintaxis de Python tiene algo del inglés (y por lo
tanto de buena parte de las lenguas que hablamos en occidente),
entonces si el objetivo es brindarle más comodidad al programador
cuya lengua materna no es el inglés, no sería necesario también
ajustar la gramática? Y en ese caso, el lenguaje seguiría siendo el
mismo? (formalmente la respuesta sería no, pero lo que pregunto es
donde se marca la línea de "esto si, aquello no").
Nada, solo un comentario.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

Post by Gabriel Genellina
PEP: 3131

Flor de quilombo se armó con eso. A nosotros casi no nos afecta
porque
son pocos caracteres de diferencia entre ASCII y "castellano". Pero me
imagino que bueno seria para un chino o un ruso poder poner variables
con los nombres que quieren. No puedo entender todavia porque hay
gente que le molesta. ¿Porque no puede leer tai? Y bueno, que se joda
el tailandes por hacer codigo que no pueda compartir, pero ¿porque
molestarme si un tailandes/japones/arabe/frances quiere hacer codigo
que él pueda leer facilmente? ¿Que le afecta a los que se oponen?
--
Sebastián Bassi (セバスティアン)
Diplomado en Ciencia y Tecnología.
GPG Fingerprint: 9470 0980 620D ABFC BE63 A4A4 A3DE C97D 8422 D43D
Club de la razón (www.clubdelarazon.org)

[Facundo Batista]

formalidad. Poco importa si el nombre de un identificador está
escrito en cirílico o plain vanilla ASCII. Aún cuando no sé
mandarin, si el día de mañana me toca leer un programa con
caracteres chinos, voy a poder entenderlo igual porque la gramática y

Falso. Una variable se llama 並非其城堡的本名, y la otra se llama 並非其泛堡的本名.

¿Es tan fácil seguir el código como si dijesen "lhdurlh" y "dqpqow"?

Fijate que mi hincapié no es en el lenguaje, sino en cuan acostumbrado
está tu cerebro a recordar visualmente formas...

Slds.

[Ariel Rodriguez]

Facundo, creo que los dos estamos diciendo exactamente lo mismo.
Tenes toda la razón del mundo al afirmar que es más fácil (para
nosotros) interpretar un programa con identificadores en ASCII que
uno con caracteres chinos. Lo que yo intenté argumentar (pobremente,
claro está) es que si bien el nombre de los identificadores es de
suma importancia para compartir código, el programa no se rompería
si los identificadores carecieran de sentido semántico. Y claro, el
factor de los caracteres es también muy importante. Cómo vos
argumentas, sería mucho más difícil seguir un identificador suyo
nombre está escrito en un alfabeto desconocido, que seguir al mismo
identificador con un nombre que puede no significar nada para
nosotros pero al menos está escrito en el alfabeto que conocemos. A
eso agrego que aun cuando sea mucho más difícil, no es imposible (al
menos en principio, después hay que ver si tiene sentido práctico)
seguir un programa con identificadores escritos en alfabetos
desconocidos. ¿Logre explicarme mejor? De nos ser así por favor
escribime porque estoy seguro que estamos diciendo lo mismo.
De hecho, si te fijas en la primera parte del mail argumento que por
una cuestión de estilo y practicidad, me parece que siempre es mejor
escribir código pensando que lo va a leer alguien más (aunque ese
alguien más sea uno mismo dentro de cuatro años). Y si bien es
cierto que hoy son muchos más los programadores cuyo idioma materno
no es el inglés, y hay mucha gente que utiliza alfabetos que nos son
extraños, me parece que podemos acordar que el alfabeto de facto es
el ASCII y creo que sería una buena política de estilo usar solo
ASCII para código que se va a mostrar al mundo exterior (y casi te
diría que elevaría la restricción para decir que los
identificadores de una interface tendrían que ser nombrados en
inglés que tiene mucho de lingua franca en nuestro gremio, pero esa
es otra discusión que podemos dejar para más adelante). El código
fuente de un programa debería ser, ante todo, una forma de
comunicación, y en particular, para el caso de los lenguajes de alto
nivel, de comunicación entre humanos. Por eso me parece que por más
que los chinos sean un sexto de la población, sería más difícil de
compartir código escrito en chino.
En esencia, el soporte a alfabetos no ASCII me parece que es más un
problema a nivel comunicación entre programadores que a nivel
lenguaje de programación. Si quieren agregar Unicode para que alguien
pueda nombrar una clase Ñandú, me parece no va a romper ningún
programa, pero si después ese mismo alguien quiere compartir el
código con alguien en Budapest, y a lo mejor el nombre Ñandú ya no
es tan buena idea.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

formalidad. Poco importa si el nombre de un identificador está
escrito en cirà lico o plain vanilla ASCII. Aún cuando no sé
mandarin, si el dà a de mañana me toca leer un programa con
caracteres chinos, voy a poder entenderlo igual porque la
gramática y

Falso. Una variable se llama ÀžŠéşå
¶åŞŜå ¡çš„Êœ¬å, y la otra se llama ÀžŠéşå
¶Ê³›å ¡çš„Êœ¬å.
¿Es tan fácil seguir el código como si dijesen "lhdurlh" y
"dqpqow"?
Fijate que mi hincapié no es en el lenguaje, sino en cuan
acostumbrado
está tu cerebro a recordar visualmente formas...
Slds.
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Lucio Torre]

Post by Facundo Batista

formalidad. Poco importa si el nombre de un identificador está
escrito en cirílico o plain vanilla ASCII. Aún cuando no sé
mandarin, si el día de mañana me toca leer un programa con
caracteres chinos, voy a poder entenderlo igual porque la gramática y

Falso. Una variable se llama 並非其城堡的本名, y la otra se llama 並非其泛堡的本名.
¿Es tan fácil seguir el código como si dijesen "lhdurlh" y "dqpqow"?

Creo que el tema es que el que tiene la necesidad deberia levantar la
mano y argumentar por ella. En Argentina, segun me parece, nadie se
muere por un acento o un dieresis o algo. Pero nos preocupa lo que haga
un chino. Si fuese solo por nosotros, yo no pondria el feature en el
lenguage. Pero habria que ver que opinan los chinos[1].

Lucio
[1] chino: dicese de cualquier persona del otro lado del mundo que usa
logogramas para escribir.

[Lucio Torre]

Post by Lucio Torre
[1] chino: dicese de cualquier persona del otro lado del mundo que usa
logogramas para escribir.

Pensandolo mejor, los arabes tambien me suenan chinos y usan alfabeto.

[Ariel Rodriguez]

Me gusto, y si, tenes razón.
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

formalidad. Poco importa si el nombre de un identificador está
escrito en cirà lico o plain vanilla ASCII. Aún cuando no
sé mandarin, si el dà a de mañana me toca leer un programa
con caracteres chinos, voy a poder entenderlo igual porque la
gramática y

Falso. Una variable se llama ÀžŠéşå

¶åŞŜå ¡çš„Êœ¬å, y la otra se llama ÀžŠéşå
¶Ê³›å ¡çš„Êœ¬å.

¿Es tan fácil seguir el código como si dijesen "lhdurlh" y
"dqpqow"?

Creo que el tema es que el que tiene la necesidad deberia levantar
la mano y argumentar por ella. En Argentina, segun me parece, nadie
se muere por un acento o un dieresis o algo. Pero nos preocupa lo
que haga un chino. Si fuese solo por nosotros, yo no pondria el
feature en el lenguage. Pero habria que ver que opinan los chinos[1].
Lucio
[1] chino: dicese de cualquier persona del otro lado del mundo que
usa logogramas para escribir.
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Lucio Torre]

Falso. Una variable se llama 並非å

¶åŸŽå ¡çš„本名, y la otra se llama 並非å
¶æ³›å ¡çš„本名.

¿Es tan fácil seguir el código como si dijesen "lhdurlh" y "dqpqow"?

Otro tema para tener en cuenta: cuando facundo mando este mensaje
originalmente yo podia ver los caracteres chinos y los acentos. Ahora es
todo basura! Creo que el mundo no esta listo para unicode que funcione.

Lucio

[Facundo Batista]

Post by Lucio Torre
Otro tema para tener en cuenta: cuando facundo mando este mensaje
originalmente yo podia ver los caracteres chinos y los acentos. Ahora es
todo basura! Creo que el mundo no esta listo para unicode que funcione.

Tu respuesta yo la veo ok... pero el mensaje de Ariel Rodriguez está
roto... Ariel, ¿usás outlook?

Slds...

[Ariel Rodriguez]

Nope, mail.app (Mac)
Ariel Rodriguez [Design and Coding]
Contact: mischa.cotlar-***@public.gmane.org | Skype: mischa_cotlar
PGP Fingerprint: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

Post by Facundo Batista

Post by Lucio Torre
Otro tema para tener en cuenta: cuando facundo mando este mensaje
originalmente yo podia ver los caracteres chinos y los acentos. Ahora es
todo basura! Creo que el mundo no esta listo para unicode que
funcione.

Tu respuesta yo la veo ok... pero el mensaje de Ariel Rodriguez está
roto... Ariel, ¿usás outlook?
Slds...
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Lucio Torre]

Post by Ariel Rodriguez
Nope, mail.app (Mac)
me *Ariel Rodriguez* [Design and Coding]
*PGP Fingerprint*: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

De paso, mandar mail HTML con imagenes en otro sitio puede ser
considerado poco educado:
Codigo en tu mail:

<IMG = src=3D"Loading Image..." alt=3D"me" = style=3D"height:40px; width:40px; float: left; padding:0;">


referencias:
http://en.wikipedia.org/wiki/Web_bug

salud.

[Ariel Rodriguez]

ok, soy un malo. Disculpas.
Va sin firma.
Ariel

Post by Lucio Torre

Post by Ariel Rodriguez
Nope, mail.app (Mac)
me *Ariel Rodriguez* [Design and Coding]
*PGP Fingerprint*: 3101 4AE7 5C78 158B 0B5E 0370 DE68 5E41 7D82 37A4

De paso, mandar mail HTML con imagenes en otro sitio puede ser
<IMG = src=3D"http://www.members.lycos.co.uk/euler/rulo.jpg"
0;">
http://en.wikipedia.org/wiki/Web_bug
salud.
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/

[Sebastian Bassi]

Post by Lucio Torre
Otro tema para tener en cuenta: cuando facundo mando este mensaje
originalmente yo podia ver los caracteres chinos y los acentos. Ahora es
todo basura! Creo que el mundo no esta listo para unicode que funcione.

Es cierto, entre los idas y vueltas se fue haciendo pelota :)
Pero esa vision es un circulo vicioso, no lo uso porque muchas apps no
lo bancan, y por lo tanto los programadores de las apps no lo
actualizan porque pocos lo usan.
Como los ISP que no dan soporte a clientes con Linux porque hay pocos
usuarios, y hay usuarios que no usan Linux porque sus ISP no lo
soportan.

[Daniel F Moisset]

Post by Facundo Batista
Falso. Una variable se llama 並非其城堡的本名, y la otra se llama 並非其泛堡的本名.

Sin decirlo por el tema general, sino fijandome solo el ejemplo, no me
parece bueno el ejemplo en el sentido de que esos dos nombres que
pusiste son larguísimos... podría igualmente decir que es dificil
identificar dos variables que se llaman

hola_soy_un_nombre_de_una_variable_que_en_realidad_es_solo_un_nombre_de_un_objeto
y otra hola_soy_un_nombre_de_una_variable_que_en_realidad_es_un_nombre_de_otro_objeto

aunque sea cortito el ejemplo tuyo, la densidad de información es
altísima. Un ejemplo más valido sería comparar 其泛 con 其城

[Resumen: No me puse a pensar si tu argumento es bueno o no, pero la
forma de plantearlo es mala]

Saludo,
D.

[Sebastian Bassi]

Que se supone que ven aca? (yo veo cuadrados con 4 caracteres adentro)
(captura please :)

Post by Daniel F Moisset

Post by Facundo Batista
並非其城堡的本名, y la otra se llama 並非其泛堡的本名.

...

Post by Daniel F Moisset
其泛 con 其城

[Facundo Batista]

Post by Sebastian Bassi
Que se supone que ven aca? (yo veo cuadrados con 4 caracteres adentro)
(captura please :)

Yo veo caracteres chinos, o al menos orientales, de los que, audazmente,
clasificaría de ideogramas.

Post by Sebastian Bassi

Post by Daniel F Moisset

Post by Facundo Batista
並非其城堡的本名, y la otra se llama 並非其泛堡的本名.

...

Post by Daniel F Moisset
其泛 con 其城

¿Qué cliente de news o mail estás usando?

Slds.

[Sebastian Bassi]

Post by Facundo Batista
¿Qué cliente de news o mail estás usando?

Gmail con FF en Linux, pero debe ser porque no tengo esos fonts
instalados o porque en el FF tengo puesto que en View Char encodding
UTF-8.
Asi lo veo:
Loading Image...

[Gabriel Genellina]

En Thu, 24 May 2007 15:48:54 -0300, Sebastian Bassi

Post by Sebastian Bassi
Que se supone que ven aca? (yo veo cuadrados con 4 caracteres adentro)
(captura please :)

Yo, esta porquería:
Loading Image...

Pero creo que es por el font monoespaciado que elegi para mostrar los
mensajes, el codigo Python se lee mucho mejor asi...

[Carlos G Alvarez]

No veo porque no dejarles tener variables en chino que no podamos
entender. Despues de todo eso no serviria para codigo abierto no
chino. De hecho, si hacemos el programa en caracteres ingleses pero en
castella no tampoco lo aceptarian. ¿Que les parece que obliguemos a
todaaa la comunidad python a escribir codigo solo en ingles?

Por otro lado lo que considero que tendria que estar si o si es que el
chino se pueda escribir dentro de un string.

s = '並非其泛' + '堡的本名¿'

Me parece fundamental. El poner codigos de unicode tipo \u16a3 me
parece que es lo mismo para el que no sabe leer chino pero totalmente
in

[alejandro david weil]

Post by Carlos G Alvarez
Por otro lado lo que considero que tendria que estar si o si es que el
chino se pueda escribir dentro de un string.
s = '並非其泛' + '堡的本名¿'
Me parece fundamental. El poner codigos de unicode tipo \u16a3 me
parece que es lo mismo para el que no sabe leer chino pero totalmente
inmanejable para el que vive en chino.

Creo que eso funciona Carlos, proba este test.py :

# -*- coding: utf-8 -*-
s = '並非其泛'
print s


(asegurate de que el contenido del file lo grabes en utf-8, sinó vas a
tener que cambiar la primer linea!).

Saludos,
dave

[alejandro david weil]

Post by alejandro david weil

Post by Carlos G Alvarez
Por otro lado lo que considero que tendria que estar si o si es que el
chino se pueda escribir dentro de un string.
s = '並非其泛' + '堡的本名¿'

# -*- coding: utf-8 -*-
(asegurate de que el contenido del file lo grabes en utf-8, sinó vas a
tener que cambiar la primer linea!).

Ah, fijate que si no ponés esa primera linea (o en la segunda a lo
sumo), te tira un error como este:
..$ python testcharset.py
File "testcharset.py", line 1
SyntaxError: Non-ASCII character '\xe4' in file testcharset.py on line
1, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details

En esa página podes ver un poco mas formalmente lo relativo a esa
linea *coding* ..

saludos!