Qué hay de nuevo en Python 2.0
******************************

Autor:
   A.M. Kuchling y Moshe Zadka


Introducción
============

El 16 de octubre de 2000 se publicó una nueva versión de Python, la
2.0. Este artículo cubre las emocionantes nuevas características de la
2.0, destaca algunos otros cambios útiles y señala algunos cambios
incompatibles que pueden requerir reescribir el código.

El desarrollo de Python nunca se detiene por completo entre versiones,
y siempre se envía un flujo constante de correcciones de errores y
mejoras. Una gran cantidad de correcciones menores, algunas
optimizaciones, cadenas de documentación adicionales y mejores
mensajes de error entraron en 2.0; enumerarlos a todos sería
imposible, pero ciertamente son significativos. Consulte los registros
de CVS disponibles públicamente si desea ver la lista completa. Este
progreso se debe a que a los cinco desarrolladores que trabajan para
PythonLabs ahora se les paga por dedicar sus días a corregir errores,
y también a la mejora de la comunicación resultante de la migración a
SourceForge.


¿Qué pasa con Python 1.6?
=========================

Python 1.6 puede considerarse como la versión de Python de las
Obligaciones Contractuales. Después de que el equipo principal de
desarrollo dejara el CNRI en mayo de 2000, el CNRI pidió que se creara
una versión 1.6 que contuviera todo el trabajo sobre Python que se
había realizado en el CNRI. Por lo tanto, Python 1.6 representa el
estado del árbol CVS en mayo de 2000, siendo la novedad más importante
el soporte de Unicode. El desarrollo continuó después de mayo, por
supuesto, así que el árbol 1.6 recibió algunas correcciones para
asegurar que es compatible con Python 2.0. 1.Por lo tanto, la 6 es
parte de la evolución de Python, y no una rama lateral.

Entonces, ¿deberías interesarte mucho por Python 1.6?  Probablemente
no. Las versiones 1.6final y 2.0beta1 se publicaron el mismo día (5 de
septiembre de 2000), y el plan es finalizar Python 2.0 en un mes más o
menos. Si tienes aplicaciones que mantener, no parece que tenga mucho
sentido romper cosas al pasar a la 1.6, arreglarlas, y luego tener
otra ronda de roturas dentro de un mes al pasar a la 2.0; es mejor
pasar directamente a la 2.0. La mayoría de las características
realmente interesantes descritas en este documento sólo están en la
2.0, porque se hizo mucho trabajo entre mayo y septiembre.


Nuevo proceso de desarrollo
===========================

El cambio más importante en Python 2.0 puede que no sea en el código
en absoluto, sino en la forma de desarrollar Python: en mayo de 2000
los desarrolladores de Python comenzaron a utilizar las herramientas
puestas a disposición por SourceForge para almacenar el código fuente,
rastrear los informes de errores y gestionar la cola de envíos de
parches. Para informar de errores o enviar parches para Python 2.0,
utilice las herramientas de seguimiento de errores y gestión de
parches disponibles en la página del proyecto Python, situada en
https://sourceforge.net/projects/python/.

El más importante de los servicios alojados ahora en SourceForge es el
árbol CVS de Python, el repositorio de versiones controladas que
contiene el código fuente de Python. Anteriormente, había unas 7
personas que tenían acceso de escritura al árbol CVS, y todos los
parches tenían que ser inspeccionados y comprobados por una de las
personas de esta corta lista. Obviamente, esto no era muy escalable.
Al trasladar el árbol CVS a SourceForge, fue posible conceder acceso
de escritura a más personas; en septiembre de 2000 había 27 personas
que podían revisar los cambios, un aumento de cuatro veces. Esto hace
posible cambios a gran escala que no se intentarían si tuvieran que
pasar por el pequeño grupo de desarrolladores del núcleo. Por ejemplo,
un día a Peter Schneider-Kamp se le ocurrió dejar de lado la
compatibilidad con K&R C y convertir el código fuente de Python a ANSI
C. Después de obtener la aprobación en la lista de correo de python-
dev, se lanzó a una ráfaga de revisiones que duró aproximadamente una
semana, otros desarrolladores se unieron para ayudar, y el trabajo
estaba hecho. Si sólo hubiera habido 5 personas con acceso de
escritura, probablemente esa tarea habría sido considerada como
"agradable, pero no vale la pena el tiempo y el esfuerzo necesarios" y
nunca se habría realizado.

El cambio al uso de los servicios de SourceForge ha dado lugar a un
notable aumento de la velocidad de desarrollo. Ahora los parches se
envían, se comentan, son revisados por otras personas además del
remitente original, y van de un lado a otro hasta que se considera que
el parche merece ser revisado. Los errores se rastrean en una
ubicación central y se pueden asignar a una persona específica para
que los corrija, y podemos contar el número de errores abiertos para
medir el progreso. Esto no ha tenido un coste: los desarrolladores
tienen ahora más correo electrónico con el que lidiar, más listas de
correo que seguir, y se han tenido que escribir herramientas
especiales para el nuevo entorno. Por ejemplo, SourceForge envía por
defecto mensajes de correo electrónico de notificación de parches y
errores que son completamente inútiles, por lo que Ka-Ping Yee
escribió un raspador de pantalla HTML que envía mensajes más útiles.

La facilidad para añadir código provocó algunos problemas iniciales de
crecimiento, como el hecho de que el código se registrara antes de
estar listo o sin obtener un acuerdo claro del grupo de
desarrolladores. El proceso de aprobación que ha surgido es algo
similar al utilizado por el grupo Apache. Los desarrolladores pueden
votar +1, +0, -0 o -1 sobre un parche; +1 y -1 denotan aceptación o
rechazo, mientras que +0 y -0 significan que el desarrollador es
mayormente indiferente al cambio, aunque con un ligero sesgo positivo
o negativo. El cambio más significativo con respecto al modelo de
Apache es que la votación es esencialmente consultiva, lo que permite
a Guido van Rossum, que tiene el estatus de Dictador Benevolente
Vitalicio, saber cuál es la opinión general. Puede seguir ignorando el
resultado de una votación y aprobar o rechazar un cambio aunque la
comunidad no esté de acuerdo con él.

Producir un parche real es el último paso en la adición de una nueva
característica, y suele ser fácil en comparación con la tarea anterior
de llegar a un buen diseño. Las discusiones sobre nuevas
funcionalidades a menudo pueden explotar en largos hilos de la lista
de correo, haciendo que la discusión sea difícil de seguir, y nadie
puede leer todos los mensajes en python-dev. Por lo tanto, se ha
establecido un proceso relativamente formal para escribir Propuestas
de Mejora de Python (PEPs), siguiendo el modelo del proceso RFC de
Internet. Las PEP son borradores de documentos que describen una nueva
característica propuesta, y se revisan continuamente hasta que la
comunidad llega a un consenso, aceptando o rechazando la propuesta.
Cita de la introducción de **PEP 1**, "PEP Purpose and Guidelines":

   PEP son las siglas de Python Enhancement Proposal. Un PEP es un
   documento de diseño que proporciona información a la comunidad de
   Python, o que describe una nueva característica para Python. El PEP
   debe proporcionar una especificación técnica concisa de la
   característica y una justificación de la misma.

   Pretendemos que los PEPs sean los mecanismos principales para
   proponer nuevas características, para recoger las opiniones de la
   comunidad sobre un tema y para documentar las decisiones de diseño
   que se han tomado en Python. El autor del PEP es responsable de
   crear consenso dentro de la comunidad y de documentar las opiniones
   discrepantes.

Read the rest of **PEP 1** for the details of the PEP editorial
process, style, and format.  PEPs are kept in the Python CVS tree on
SourceForge, though they're not part of the Python 2.0 distribution,
and are also available in HTML form from https://peps.python.org/.  As
of September 2000, there are 25 PEPs, ranging from **PEP 201**,
"Lockstep Iteration", to PEP 225, "Elementwise/Objectwise Operators".


Unicode
=======

La mayor novedad de Python 2.0 es un nuevo tipo de datos fundamental:
Las cadenas Unicode. Unicode utiliza números de 16 bits para
representar los caracteres en lugar de los 8 bits utilizados por
ASCII, lo que significa que se pueden admitir 65.536 caracteres
distintos.

La interfaz final para el soporte de Unicode se alcanzó a través de
innumerables discusiones, a menudo tormentosas, en la lista de correo
de python-dev, y fue implementada en su mayor parte por Marc-André
Lemburg, basándose en una implementación del tipo de cadena Unicode de
Fredrik Lundh. Una explicación detallada de la interfaz fue escrita
como **PEP 100**, "Python Unicode Integration". Este artículo se
limitará a cubrir los puntos más significativos de las interfaces
Unicode.

In Python source code, Unicode strings are written as "u"string"".
Arbitrary Unicode characters can be written using a new escape
sequence, "\u*HHHH*", where *HHHH* is a 4-digit hexadecimal number
from 0000 to FFFF.  The existing "\x*HH*" escape sequence can also be
used, and octal escapes can be used for characters up to U+01FF, which
is represented by "\777".

Las cadenas Unicode, al igual que las cadenas normales, son un tipo de
secuencia inmutable. Pueden ser indexadas y cortadas, pero no
modificadas en su lugar. Las cadenas Unicode tienen un método "encode(
[encoding] )" que retorna una cadena de 8 bits en la codificación
deseada. Las codificaciones son nombradas por cadenas, como "'ascii'",
"'utf-8'", "'iso-8859-1'", o lo que sea. Se define una API de códecs
para implementar y registrar nuevas codificaciones que luego están
disponibles en todo el programa Python. Si no se especifica una
codificación, la codificación por defecto suele ser ASCII de 7 bits,
aunque puede cambiarse para tu instalación de Python llamando a la
función "sys.setdefaultencoding(encoding)" en una versión
personalizada de "site.py".

La combinación de cadenas de 8 bits y Unicode siempre fuerza
conversión a Unicode, utilizando la codificación ASCII por defecto; el
resultado de "'a' + u'bc'" es "u'abc'".

Se han añadido nuevas funciones incorporadas y se han modificado las
existentes para que sean compatibles con Unicode:

* "unichr(ch)" retorna una cadena Unicode de 1 carácter, que contiene
  el carácter *ch*.

* "ord(u)", donde *u* es una cadena regular o Unicode de 1 carácter,
  retorna el número del carácter como un entero.

* "unicode(string [, encoding] [, errors] )" crea una cadena Unicode a
  partir de una cadena de 8 bits. "encoding" es una cadena que nombra
  la codificación a utilizar. El parámetro "errors" especifica el
  tratamiento de los caracteres que no son válidos para la
  codificación actual; pasar "'strict" como valor hace que se lance
  una excepción en cualquier error de codificación, mientras que
  "'ignore" hace que los errores se ignoren silenciosamente y
  "'replace" utiliza U+FFFD, el carácter oficial de reemplazo, en caso
  de cualquier problema.

* La sentencia "exec", y varias funciones integradas como "eval()",
  "getattr()", y "setattr()" también aceptarán cadenas Unicode así
  como cadenas regulares. (Es posible que en el proceso de corrección
  de esto se hayan pasado por alto algunas funciones incorporadas; si
  encuentra una función incorporada que acepte cadenas pero que no
  acepte cadenas Unicode en absoluto, por favor, infórmelo como un
  error)

Un nuevo módulo, "unicodedata", proporciona una interfaz para las
propiedades de los caracteres Unicode. Por ejemplo,
"unicodedata.category(u'A')" retorna la cadena de 2 caracteres 'Lu',
la 'L' denota que es una letra, y la 'u' significa que es mayúscula.
"unicodedata.bidirectional(u'\u0660')" retorna 'AN', lo que significa
que U+0660 es un número árabe.

El módulo "codecs" contiene funciones para buscar codificaciones
existentes y registrar otras nuevas. A menos que quiera implementar
una nueva codificación, lo más habitual es que utilice la función
"codecs.lookup(encoding)", que retorna una tupla de 4 elementos:
"(encode_func, decode_func, stream_reader, stream_writer)".

* *encode_func* es una función que toma una cadena Unicode, y retorna
  una 2-tupla "(string, length)". *string* es una cadena de 8 bits que
  contiene una porción (tal vez toda) de la cadena Unicode convertida
  a la codificación dada, y *longitud* indica la cantidad de cadena
  Unicode convertida.

* *decode_func* es lo opuesto a *encode_func*, tomando una cadena de 8
  bits y retornando una 2-tupla "(ustring, length)", que consiste en
  la cadena Unicode resultante *ustring* y el entero *length* que dice
  cuánto de la cadena de 8 bits se consumió.

* *stream_reader* is a class that supports decoding input from a
  stream. *stream_reader(file_obj)* returns an object that supports
  the "read()", "readline()", and "readlines()" methods.  These
  methods will all translate from the given encoding and return
  Unicode strings.

* *stream_writer*, similarly, is a class that supports encoding output
  to a stream.  *stream_writer(file_obj)* returns an object that
  supports the "write()" and "writelines()" methods.  These methods
  expect Unicode strings, translating them to the given encoding on
  output.

Por ejemplo, el siguiente código escribe una cadena Unicode en un
archivo, codificándola como UTF-8:

   import codecs

   unistr = u'\u0660\u2000ab ...'

   (UTF8_encode, UTF8_decode,
    UTF8_streamreader, UTF8_streamwriter) = codecs.lookup('UTF-8')

   output = UTF8_streamwriter( open( '/tmp/output', 'wb') )
   output.write( unistr )
   output.close()

El siguiente código leería la entrada UTF-8 del archivo:

   input = UTF8_streamreader( open( '/tmp/output', 'rb') )
   print repr(input.read())
   input.close()

Las expresiones regulares compatibles con Unicode están disponibles a
través del módulo "re", que tiene una nueva implementación subyacente
llamada SRE escrita por Fredrik Lundh de Secret Labs AB.

Se ha añadido una opción de línea de comandos "-U" que hace que el
compilador de Python interprete todos los literales de cadena como
literales de cadena Unicode. Esta opción está pensada para ser
utilizada en las pruebas y para asegurar el futuro de su código
Python, ya que alguna versión futura de Python puede dejar de soportar
cadenas de 8 bits y proporcionar sólo cadenas Unicode.


Comprensión de listas
=====================

Las listas son un tipo de datos muy útil en Python, y muchos programas
manipulan una lista en algún momento. Dos operaciones comunes en las
listas son hacer un bucle sobre ellas, y escoger los elementos que
cumplen un cierto criterio, o aplicar alguna función a cada elemento.
Por ejemplo, dada una lista de cadenas, podrías querer sacar todas las
cadenas que contengan una determinada subcadena, o quitar los espacios
en blanco de cada línea.

Las funciones "map()" y "filter()" existentes pueden usarse para este
propósito, pero requieren una función como uno de sus argumentos. Esto
está bien si hay una función incorporada que se puede pasar
directamente, pero si no la hay, hay que crear una pequeña función
para hacer el trabajo requerido, y las reglas de ámbito de Python
hacen que el resultado sea feo si la pequeña función necesita
información adicional. Tomemos el primer ejemplo del párrafo anterior,
encontrar todas las cadenas de la lista que contienen una subcadena
dada. Podrías escribir lo siguiente para hacerlo:

   # Given the list L, make a list of all strings
   # containing the substring S.
   sublist = filter( lambda s, substring=S:
                        string.find(s, substring) != -1,
                     L)

Debido a las reglas de ámbito de Python, se utiliza un argumento por
defecto para que la función anónima creada por la expresión "lambda"
sepa qué subcadena se está buscando. Las comprensiones de lista hacen
esto más limpio:

   sublist = [ s for s in L if string.find(s, S) != -1 ]

Las comprensiones de listas tienen la forma:

   [ expression for expr in sequence1
                for expr2 in sequence2 ...
                for exprN in sequenceN
                if condition ]

Las cláusulas "for"..."in" contienen las secuencias a iterar. Las
secuencias no tienen por qué tener la misma longitud, ya que no se
itera sobre ellas en paralelo, sino de izquierda a derecha; esto se
explica más claramente en los párrafos siguientes. Los elementos de la
lista generada serán los valores sucesivos de la *expresión*. La
cláusula final "if" es opcional; si está presente, la *expresión* sólo
se evalúa y se añade al resultado si la *condición* es verdadera.

Para dejar muy clara la semántica, una comprensión de lista equivale
al siguiente código de Python:

   for expr1 in sequence1:
       for expr2 in sequence2:
       ...
           for exprN in sequenceN:
                if (condition):
                     # Append the value of
                     # the expression to the
                     # resulting list.

Esto significa que cuando hay múltiples cláusulas "for"..."in", la
lista resultante será igual al producto de las longitudes de todas las
secuencias. Si tiene dos listas de longitud 3, la lista de salida
tendrá 9 elementos:

   seq1 = 'abc'
   seq2 = (1,2,3)
   >>> [ (x,y) for x in seq1 for y in seq2]
   [('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1),
   ('c', 2), ('c', 3)]

Para evitar introducir una ambigüedad en la gramática de Python, si
*expresión* está creando una tupla, debe estar rodeada de paréntesis.
La primera comprensión de la lista a continuación es un error de
sintaxis, mientras que la segunda es correcta:

   # Syntax error
   [ x,y for x in seq1 for y in seq2]
   # Correct
   [ (x,y) for x in seq1 for y in seq2]

La idea de las comprensiones de listas procede originalmente del
lenguaje de programación funcional Haskell (https://www.haskell.org).
Greg Ewing fue el que más abogó por añadirlas a Python y escribió el
parche inicial de comprensión de listas, que luego se discutió durante
un tiempo aparentemente interminable en la lista de correo de python-
dev y se mantuvo actualizada por Skip Montanaro.


Asignación aumentada
====================

Los operadores de asignación aumentados, otra característica
largamente solicitada, han sido añadidos a Python 2.0. Los operadores
de asignación aumentados incluyen "+=", "-=", "*=", etc. Por ejemplo,
la sentencia "a += 2" incrementa el valor de la variable "a" en 2, lo
que equivale a la sentencia algo más larga "a = a + 2".

The full list of supported assignment operators is "+=", "-=", "*=",
"/=", "%=", "**=", "&=", "|=", "^=", ">>=", and "<<=".  Python classes
can override the augmented assignment operators by defining methods
named "__iadd__()", "__isub__()", etc.  For example, the following
"Number" class stores a number and supports using += to create a new
instance with an incremented value.

   class Number:
       def __init__(self, value):
           self.value = value
       def __iadd__(self, increment):
           return Number( self.value + increment)

   n = Number(5)
   n += 3
   print n.value

The "__iadd__()" special method is called with the value of the
increment, and should return a new instance with an appropriately
modified value; this return value is bound as the new value of the
variable on the left-hand side.

Los operadores de asignación aumentada se introdujeron por primera vez
en el lenguaje de programación C, y la mayoría de los lenguajes
derivados de C, como **awk**, C++, Java, Perl y PHP también los
soportan. El parche de asignación aumentada fue implementado por
Thomas Wouters.


Métodos de cadena de caracteres
===============================

Until now string-manipulation functionality was in the "string"
module, which was usually a front-end for the "strop" module written
in C.  The addition of Unicode posed a difficulty for the "strop"
module, because the functions would all need to be rewritten in order
to accept either 8-bit or Unicode strings.  For functions such as
"string.replace()", which takes 3 string arguments, that means eight
possible permutations, and correspondingly complicated code.

En cambio, Python 2.0 traslada el problema al tipo de cadena de
caracteres, haciendo que la funcionalidad de manipulación de cadenas
esté disponible a través de métodos tanto en cadenas de 8 bits como en
cadenas Unicode.

   >>> 'andrew'.capitalize()
   'Andrew'
   >>> 'hostname'.replace('os', 'linux')
   'hlinuxtname'
   >>> 'moshe'.find('sh')
   2

Una cosa que no ha cambiado, a pesar de una notable broma de April
Fools, es que las cadenas de Python son inmutables. Así, los métodos
de cadenas retornan cadenas nuevas, y no modifican la cadena sobre la
que operan.

El antiguo módulo "string" sigue existiendo por compatibilidad con el
pasado, pero actúa principalmente como un front-end para los nuevos
métodos de cadena de caracteres.

Two methods which have no parallel in pre-2.0 versions, although they
did exist in JPython for quite some time, are "startswith()" and
"endswith()". "s.startswith(t)" is equivalent to "s[:len(t)] == t",
while "s.endswith(t)" is equivalent to "s[-len(t):] == t".

One other method which deserves special mention is "join()".  The
"join()" method of a string receives one parameter, a sequence of
strings, and is equivalent to the "string.join()" function from the
old "string" module, with the arguments reversed. In other words,
"s.join(seq)" is equivalent to the old "string.join(seq, s)".


Recogida de basura de los ciclos
================================

La implementación en C de Python utiliza el conteo de referencias para
implementar la recolección de basura. Cada objeto de Python mantiene
un recuento del número de referencias que apuntan a sí mismo, y ajusta
el recuento a medida que se crean o destruyen referencias. Una vez que
el recuento de referencias llega a cero, el objeto deja de ser
accesible, ya que es necesario tener una referencia a un objeto para
acceder a él, y si el recuento es cero, ya no existen referencias.

El conteo de referencias tiene algunas propiedades agradables: es
fácil de entender e implementar, y la implementación resultante es
portable, bastante rápida, y reacciona bien con otras bibliotecas que
implementan sus propios esquemas de manejo de memoria. El mayor
problema del conteo de referencias es que a veces no se da cuenta de
que los objetos ya no son accesibles, lo que provoca una fuga de
memoria. Esto ocurre cuando hay ciclos de referencias.

Consideremos el ciclo más simple posible, una instancia de clase que
tiene una referencia a sí misma:

   instance = SomeClass()
   instance.myself = instance

Después de ejecutar las dos líneas de código anteriores, la cuenta de
referencias de "instance" es 2; una referencia es de la variable
llamada "'instance", y la otra es del atributo "myself" de la
instancia.

Si la siguiente línea de código es "del instance", ¿qué ocurre?  La
cuenta de referencias de "instance" se reduce en 1, por lo que tiene
una cuenta de referencias de 1; la referencia en el atributo "myself"
sigue existiendo. Sin embargo, la instancia ya no es accesible a
través del código de Python, y podría ser eliminada. Varios objetos
pueden participar en un ciclo si tienen referencias entre sí, haciendo
que todos los objetos se filtren.

Python 2.0 soluciona este problema ejecutando periódicamente un
algoritmo de detección de ciclos que busca los ciclos inaccesibles y
borra los objetos implicados. Un nuevo módulo "gc" proporciona
funciones para realizar una recolección de basura, obtener
estadísticas de depuración y afinar los parámetros del recolector.

Ejecutar el algoritmo de detección de ciclos lleva algo de tiempo, y
por lo tanto resultará en una sobrecarga adicional. Se espera que
después de que hayamos adquirido experiencia con la recogida de ciclos
al utilizar la versión 2.0, Python 2.1 sea capaz de minimizar la
sobrecarga con un cuidadoso ajuste. Todavía no es obvio cuánto
rendimiento se pierde, porque la evaluación comparativa de esto es
difícil y depende crucialmente de la frecuencia con la que el programa
crea y destruye objetos. La detección de ciclos puede ser desactivada
cuando Python es compilado, si no puede permitirse ni siquiera una
pequeña penalización de velocidad o sospecha que la recolección de
ciclos es un error, especificando la opción "--without-cycle-gc"
cuando se ejecuta el script **configure**.

Varias personas abordaron este problema y contribuyeron a una
solución. Una primera implementación del enfoque de detección de
ciclos fue escrita por Toby Kelsey. El algoritmo actual fue sugerido
por Eric Tiedemann durante una visita al CNRI, y Guido van Rossum y
Neil Schemenauer escribieron dos implementaciones diferentes, que
posteriormente fueron integradas por Neil. Muchas otras personas
ofrecieron sugerencias a lo largo del camino; los archivos de marzo de
2000 de la lista de correo python-dev contienen la mayor parte de la
discusión relevante, especialmente en los hilos titulados "Colección
de ciclos de referencia para Python" y "Finalización de nuevo".


Otros cambios en el núcleo
==========================

Se han realizado varios cambios menores en la sintaxis y las funciones
incorporadas de Python. Ninguno de los cambios es de gran alcance,
pero son conveniencias prácticas.


Cambios menores del lenguaje
----------------------------

A new syntax makes it more convenient to call a given function with a
tuple of arguments and/or a dictionary of keyword arguments. In Python
1.5 and earlier, you'd use the "apply()" built-in function: "apply(f,
args, kw)" calls the function "f()" with the argument tuple *args* and
the keyword arguments in the dictionary *kw*.  "apply()"  is the same
in 2.0, but thanks to a patch from Greg Ewing, "f(*args, **kw)" is a
shorter and clearer way to achieve the same effect.  This syntax is
symmetrical with the syntax for defining functions:

   def f(*args, **kw):
       # args is a tuple of positional args,
       # kw is a dictionary of keyword args
       ...

The "print" statement can now have its output directed to a file-like
object by following the "print" with  ">> file", similar to the
redirection operator in Unix shells. Previously you'd either have to
use the "write()" method of the file-like object, which lacks the
convenience and simplicity of "print", or you could assign a new value
to "sys.stdout" and then restore the old value.  For sending output to
standard error, it's much easier to write this:

   print >> sys.stderr, "Warning: action field not supplied"

Ahora se puede cambiar el nombre de los módulos al importarlos,
utilizando la sintaxis "import module as name" o "from module import
name as othername". El parche fue enviado por Thomas Wouters.

Un nuevo estilo de formato está disponible cuando se utiliza el
operador "%"; '%r' insertará el "repr()" de su argumento. Esto también
se añadió por consideraciones de simetría, esta vez por simetría con
el estilo de formato existente '%s', que inserta el "str()" de su
argumento. Por ejemplo, "'%r %s' % ('abc', 'abc')" retorna una cadena
que contiene "'abc' abc".

Previously there was no way to implement a class that overrode
Python's built-in "in" operator and implemented a custom version.
"obj in seq" returns true if *obj* is present in the sequence *seq*;
Python computes this by simply trying every index of the sequence
until either *obj* is found or an "IndexError" is encountered.  Moshe
Zadka contributed a patch which adds a "__contains__()" magic method
for providing a custom implementation for "in". Additionally, new
built-in objects written in C can define what "in" means for them via
a new slot in the sequence protocol.

Las versiones anteriores de Python utilizaban un algoritmo recursivo
para borrar objetos. Las estructuras de datos muy anidadas podían
hacer que el intérprete llenara la pila de C y se bloqueara; Christian
Tismer reescribió la lógica de borrado para solucionar este problema.
En una nota relacionada, la comparación de objetos recursivos se
repite infinitamente y se bloquea; Jeremy Hylton reescribió el código
para que no se bloquee, produciendo un resultado útil. Por ejemplo,
después de este código:

   a = []
   b = []
   a.append(a)
   b.append(b)

The comparison "a==b" returns true, because the two recursive data
structures are isomorphic. See the thread "trashcan and PR#7" in the
April 2000 archives of the python-dev mailing list for the discussion
leading up to this implementation, and some useful relevant links.
Note that comparisons can now also raise exceptions. In earlier
versions of Python, a comparison operation such as "cmp(a,b)" would
always produce an answer, even if a user-defined "__cmp__()" method
encountered an error, since the resulting exception would simply be
silently swallowed.

Se ha trabajado en la migración de Python a Windows de 64 bits en el
procesador Itanium, principalmente por Trent Mick de ActiveState.
(Confusamente, "sys.platform" sigue siendo "'win32'" en Win64 porque
parece que, para facilitar la migración, MS Visual C++ trata el código
como de 32 bits en Itanium). PythonWin también es compatible con
Windows CE; consulte la página de Python CE en
https://pythonce.sourceforge.net/ para obtener más información.

Otra plataforma nueva es Darwin/MacOS X; el soporte inicial para ella
está en Python 2.0. La carga dinámica funciona, si se especifica
"configure --with-dyld --with-suffix=.x". Consulte el README de la
distribución de fuentes de Python para obtener más instrucciones.

Se ha intentado aliviar uno de los defectos de Python, la a menudo
confusa excepción "NameError" cuando el código hace referencia a una
variable local antes de que se le haya asignado un valor. Por ejemplo,
el siguiente código lanza una excepción en la sentencia "print" tanto
en 1.5.2 como en 2.0; en 1.5.2 se lanza una excepción "NameError",
mientras que en 2.0 se lanza una nueva excepción "UnboundLocalError".
"UnboundLocalError" es una subclase de "NameError", así que cualquier
código existente que espere que se lance "NameError" debería seguir
funcionando.

   def f():
       print "i=",i
       i = i + 1
   f()

Se han introducido dos nuevas excepciones, "TabError" y
"IndentationError". Ambas son subclases de "SyntaxError", y se lanzan
cuando el código Python se encuentra con una sangría incorrecta.


Cambios en las funciones incorporadas
-------------------------------------

Se ha añadido un nuevo built-in, "zip(seq1, seq2, ...)". "zip()"
retorna una lista de tuplas donde cada tupla contiene el i-ésimo
elemento de cada una de las secuencias del argumento. La diferencia
entre "zip()" y "map(None, seq1, seq2)" es que "map()" rellena las
secuencias con "None" si las secuencias no tienen la misma longitud,
mientras que "zip()" trunca la lista retornada a la longitud de la
secuencia argumental más corta.

The "int()" and "long()" functions now accept an optional "base"
parameter when the first argument is a string. "int('123', 10)"
returns 123, while "int('123', 16)" returns 291.  "int(123, 16)"
raises a "TypeError" exception with the message "can't convert non-
string with explicit base".

Se ha añadido al módulo "sys" una nueva variable que contiene
información más detallada sobre la versión. "sys.version_info" es una
tupla "(major, minor, micro, level, serial)" Por ejemplo, en una
hipotética 2.0.1beta1, "sys.version_info" sería "(2, 0, 1, 'beta',
1)". *level* es una cadena como ""alpha"", ""beta"", o ""final"" para
una versión final.

Dictionaries have an odd new method, "setdefault(key, default)", which
behaves similarly to the existing "get()" method.  However, if the key
is missing, "setdefault()" both returns the value of *default* as
"get()" would do, and also inserts it into the dictionary as the value
for *key*.  Thus, the following lines of code:

   if dict.has_key( key ): return dict[key]
   else:
       dict[key] = []
       return dict[key]

puede reducirse a una única sentencia "return dict.setdefault(key,
[])".

El intérprete establece una profundidad de recursión máxima para
atrapar la recursión desbocada antes de llenar la pila de C y causar
un volcado del núcleo o GPF. Anteriormente este límite se fijaba
cuando se compilaba Python, pero en la versión 2.0 la profundidad
máxima de recursión puede leerse y modificarse usando
"sys.getrecursionlimit()" y "sys.setrecursionlimit()". El valor por
defecto es 1000, y se puede encontrar un valor máximo aproximado para
una plataforma determinada ejecutando un nuevo script,
"Misc/find_recursionlimit.py".


Adaptación a la versión 2.0
===========================

Las nuevas versiones de Python se esfuerzan por ser compatibles con
las anteriores, y el historial ha sido bastante bueno. Sin embargo,
algunos cambios se consideran lo suficientemente útiles, normalmente
porque corrigen decisiones de diseño iniciales que resultaron ser
activamente erróneas, que no siempre se puede evitar romper la
compatibilidad hacia atrás. Esta sección enumera los cambios en Python
2.0 que pueden hacer que el código Python antiguo se rompa.

The change which will probably break the most code is tightening up
the arguments accepted by some methods.  Some methods would take
multiple arguments and treat them as a tuple, particularly various
list methods such as "append()" and "insert()". In earlier versions of
Python, if "L" is a list, "L.append( 1,2 )" appends the tuple "(1,2)"
to the list.  In Python 2.0 this causes a "TypeError" exception to be
raised, with the message: 'append requires exactly 1 argument; 2
given'.  The fix is to simply add an extra set of parentheses to pass
both values as a tuple:  "L.append( (1,2) )".

The earlier versions of these methods were more forgiving because they
used an old function in Python's C interface to parse their arguments;
2.0 modernizes them to use "PyArg_ParseTuple()", the current argument
parsing function, which provides more helpful error messages and
treats multi-argument calls as errors.  If you absolutely must use 2.0
but can't fix your code, you can edit "Objects/listobject.c" and
define the preprocessor symbol "NO_STRICT_LIST_APPEND" to preserve the
old behaviour; this isn't recommended.

Some of the functions in the "socket" module are still forgiving in
this way.  For example, "socket.connect( ('hostname', 25) )" is the
correct form, passing a tuple representing an IP address, but
"socket.connect('hostname', 25)" also works. "socket.connect_ex" and
"socket.bind" are similarly easy-going.  2.0alpha1 tightened these
functions up, but because the documentation actually used the
erroneous multiple argument form, many people wrote code which would
break with the stricter checking.  GvR backed out the changes in the
face of public reaction, so for the "socket" module, the documentation
was fixed and the multiple argument form is simply marked as
deprecated; it *will* be tightened up again in a future Python
version.

El escape "\x" en los literales de cadena ahora toma exactamente 2
dígitos hexadecimales. Antes consumía todos los dígitos hexadecimales
que seguían a la 'x' y tomaba los 8 bits más bajos del resultado, por
lo que "\x123456" era equivalente a "\x56".

Las excepciones "AttributeError" y "NameError" tienen un mensaje de
error más amigable, cuyo texto será algo así como "'Spam' instance has
no attribute 'eggs'" o "name 'eggs' is not defined". Anteriormente, el
mensaje de error era simplemente la falta del nombre del atributo
"eggs", y el código escrito para aprovechar este hecho se romperá en
la versión 2.0.

Some work has been done to make integers and long integers a bit more
interchangeable.  In 1.5.2, large-file support was added for Solaris,
to allow reading files larger than 2 GiB; this made the "tell()"
method of file objects return a long integer instead of a regular
integer.  Some code would subtract two file offsets and attempt to use
the result to multiply a sequence or slice a string, but this raised a
"TypeError".  In 2.0, long integers can be used to multiply or slice a
sequence, and it'll behave as you'd intuitively expect it to; "3L *
'abc'" produces 'abcabcabc', and "(0,1,2,3)[2L:4L]" produces (2,3).
Long integers can also be used in various contexts where previously
only integers were accepted, such as in the "seek()" method of file
objects, and in the formats supported by the "%" operator ("%d", "%i",
"%x", etc.).  For example, ""%d" % 2L**64" will produce the string
"18446744073709551616".

El cambio más sutil de los enteros largos es que el "str()" de un
entero largo ya no tiene un carácter 'L' al final, aunque "repr()"
todavía lo incluye. La 'L' molestaba a muchas personas que querían
imprimir enteros largos con el mismo aspecto que los enteros normales,
ya que tenían que esforzarse por cortar el carácter. Esto ya no es un
problema en 2.0, pero el código que hace "str(longval)[:-1]" y asume
que la 'L' está ahí, ahora perderá el dígito final.

Taking the "repr()" of a float now uses a different formatting
precision than "str()".  "repr()" uses "%.17g" format string for C's
"sprintf()", while "str()" uses "%.12g" as before.  The effect is that
"repr()" may occasionally show more decimal places than  "str()", for
certain numbers.  For example, the number 8.1 can't be represented
exactly in binary, so "repr(8.1)" is "'8.0999999999999996'", while
str(8.1) is "'8.1'".

The "-X" command-line option, which turned all standard exceptions
into strings instead of classes, has been removed; the standard
exceptions will now always be classes.  The "exceptions" module
containing the standard exceptions was translated from Python to a
built-in C module, written by Barry Warsaw and Fredrik Lundh.


Extensión/Incorporación de cambios
==================================

Algunos de los cambios están bajo la cubierta, y sólo serán evidentes
para la gente que escribe módulos de extensión de C o que incrusta un
intérprete de Python en una aplicación más grande. Si no estás
tratando con la API de C de Python, puedes saltarte esta sección.

El número de versión de la API C de Python se incrementó, por lo que
las extensiones C compiladas para 1.5.2 deben ser recompiladas para
que funcionen con 2.0. En Windows, no es posible que Python 2.0
importe una extensión de terceros construida para Python 1.5.x debido
a cómo funcionan las DLL de Windows, por lo que Python lanzará una
excepción y la importación fallará.

Los usuarios del módulo ExtensionClass de Jim Fulton estarán
encantados de saber que se han añadido ganchos para que las
ExtensionClasses sean ahora compatibles con "isinstance()" y
"issubclass()". Esto significa que ya no tiene que recordar escribir
código como "if type(obj) == myExtensionClass", sino que puede
utilizar el más natural "if isinstance(obj, myExtensionClass)".

El archivo "Python/importdl.c", que era una masa de #ifdefs para
soportar la carga dinámica en muchas plataformas diferentes, fue
limpiado y reorganizado por Greg Stein. "importdl.c" es ahora bastante
pequeño, y el código específico de la plataforma se ha movido a un
montón de archivos "Python/dynload_*.c". Otra limpieza: también había
una serie de archivos "my*.h" en el directorio Include/ que contenían
varios hacks de portabilidad; se han fusionado en un único archivo,
"Include/pyport.h".

Vladimir Marangozov's long-awaited malloc restructuring was completed,
to make it easy to have the Python interpreter use a custom allocator
instead of C's standard "malloc()".  For documentation, read the
comments in "Include/pymem.h" and "Include/objimpl.h".  For the
lengthy discussions during which the interface was hammered out, see
the web archives of the 'patches' and 'python-dev' lists at
python.org.

Las versiones recientes del entorno de desarrollo GUSI para MacOS
soportan hilos POSIX. Por lo tanto, el soporte de hilos POSIX de
Python ahora funciona en Macintosh. También se ha contribuido al
soporte de hilos utilizando la biblioteca GNU "pth" del espacio de
usuario.

También se ha mejorado el soporte de hilos en Windows. Windows soporta
bloqueos de hilos que utilizan objetos del núcleo sólo en caso de
contención; en el caso común cuando no hay contención, utilizan
funciones más simples que son un orden de magnitud más rápido. Una
versión con hilos de Python 1.5.2 en NT es dos veces más lenta que una
versión sin hilos; con los cambios de la 2.0, la diferencia es sólo
del 10%. Estas mejoras fueron aportadas por Yakov Markovitch.

El código fuente de Python 2.0 ahora sólo utiliza prototipos ANSI C,
por lo que la compilación de Python ahora requiere un compilador ANSI
C, y ya no puede hacerse utilizando un compilador que sólo soporte K&R
C.

Anteriormente, la máquina virtual de Python utilizaba números de 16
bits en su bytecode, lo que limitaba el tamaño de los archivos fuente.
En particular, esto afectaba al tamaño máximo de las listas literales
y los diccionarios en el código fuente de Python; ocasionalmente, las
personas que generan código Python se encontraban con este límite. Un
parche de Charles G. Waldman eleva el límite de "2^16" a "2^{32}".

Three new convenience functions intended for adding constants to a
module's dictionary at module initialization time were added:
"PyModule_AddObject()", "PyModule_AddIntConstant()", and
"PyModule_AddStringConstant()".  Each of these functions takes a
module object, a null-terminated C string containing the name to be
added, and a third argument for the value to be assigned to the name.
This third argument is, respectively, a Python object, a C long, or a
C string.

A wrapper API was added for Unix-style signal handlers.
"PyOS_getsig()" gets a signal handler and "PyOS_setsig()" will set a
new handler.


Distutils: Facilitando la instalación de módulos
================================================

Antes de Python 2.0, la instalación de módulos era un asunto tedioso
-- no había forma de averiguar automáticamente dónde se instalaba
Python, o qué opciones del compilador se debían usar para los módulos
de extensión. Los autores de software tenían que pasar por un arduo
ritual de edición de Makefiles y archivos de configuración, que sólo
funcionaban realmente en Unix y dejaban sin soporte a Windows y MacOS.
Los usuarios de Python se enfrentaban a instrucciones de instalación
muy diferentes que variaban entre los distintos paquetes de extensión,
lo que hacía que la administración de una instalación de Python fuera
una tarea ardua.

El SIG de utilidades de distribución, liderado por Greg Ward, ha
creado las Distutils, un sistema para facilitar la instalación de
paquetes. Forman el paquete "distutils", una nueva parte de la
biblioteca estándar de Python. En el mejor de los casos, la
instalación de un módulo de Python desde el código fuente requerirá
los mismos pasos: primero simplemente hay que desempaquetar el archivo
tar o zip, y ejecutar ""python setup.py install". La plataforma será
detectada automáticamente, el compilador será reconocido, los módulos
de extensión C serán compilados, y la distribución será instalada en
el directorio apropiado. Los argumentos opcionales de la línea de
comandos proporcionan más control sobre el proceso de instalación, el
paquete distutils ofrece muchos lugares para anular los valores
predeterminados - separando la construcción de la instalación,
construyendo o instalando en directorios no predeterminados, y más.

Para usar las Distutils, necesitas escribir un script "setup.py". Para
el caso simple, cuando el software contiene sólo archivos .py, un
"setup.py" mínimo puede tener sólo unas pocas líneas:

   from distutils.core import setup
   setup (name = "foo", version = "1.0",
          py_modules = ["module1", "module2"])

El archivo "setup.py" no es mucho más complicado si el software consta
de unos pocos paquetes:

   from distutils.core import setup
   setup (name = "foo", version = "1.0",
          packages = ["package", "package.subpackage"])

Una extensión en C puede ser el caso más complicado; he aquí un
ejemplo tomado del paquete PyXML:

   from distutils.core import setup, Extension

   expat_extension = Extension('xml.parsers.pyexpat',
        define_macros = [('XML_NS', None)],
        include_dirs = [ 'extensions/expat/xmltok',
                         'extensions/expat/xmlparse' ],
        sources = [ 'extensions/pyexpat.c',
                    'extensions/expat/xmltok/xmltok.c',
                    'extensions/expat/xmltok/xmlrole.c', ]
          )
   setup (name = "PyXML", version = "0.5.4",
          ext_modules =[ expat_extension ] )

Las Distutils también pueden encargarse de crear distribuciones fuente
y binarias. El comando "sdist", ejecutado por ""python setup.py
sdist", construye una distribución fuente como "foo-1.0.tar.gz".
Añadir nuevos comandos no es difícil, ya se han aportado los comandos
"bdist_rpm" y "bdist_wininst" para crear una distribución RPM y un
instalador de Windows para el software, respectivamente. Los comandos
para crear otros formatos de distribución, como los paquetes de Debian
y los archivos ".pkg" de Solaris, se encuentran en diversas etapas de
desarrollo.

Todo esto está documentado en un nuevo manual, *Distribución de
módulos de Python*, que se une al conjunto básico de documentación de
Python.


Módulos XML
===========

Python 1.5.2 included a simple XML parser in the form of the "xmllib"
module, contributed by Sjoerd Mullender.  Since 1.5.2's release, two
different interfaces for processing XML have become common: SAX2
(version 2 of the Simple API for XML) provides an event-driven
interface with some similarities to "xmllib", and the DOM (Document
Object Model) provides a tree-based interface, transforming an XML
document into a tree of nodes that can be traversed and modified.
Python 2.0 includes a SAX2 interface and a stripped-down DOM interface
as part of the "xml" package. Here we will give a brief overview of
these new interfaces; consult the Python documentation or the source
code for complete details. The Python XML SIG is also working on
improved documentation.


Soporte de SAX2
---------------

SAX defines an event-driven interface for parsing XML.  To use SAX,
you must write a SAX handler class.  Handler classes inherit from
various classes provided by SAX, and override various methods that
will then be called by the XML parser.  For example, the
"startElement()" and "endElement()" methods are called for every
starting and end tag encountered by the parser, the "characters()"
method is called for every chunk of character data, and so forth.

La ventaja del enfoque basado en eventos es que todo el documento no
tiene que residir en la memoria en un momento dado, lo cual es
importante si estás procesando documentos realmente enormes. Sin
embargo, escribir la clase manejadora de SAX puede ser muy complicado
si se intenta modificar la estructura del documento de alguna manera
elaborada.

Por ejemplo, este pequeño programa de ejemplo define un manejador que
imprime un mensaje para cada etiqueta inicial y final, y luego analiza
el archivo "hamlet.xml" usándolo:

   from xml import sax

   class SimpleHandler(sax.ContentHandler):
       def startElement(self, name, attrs):
           print 'Start of element:', name, attrs.keys()

       def endElement(self, name):
           print 'End of element:', name

   # Create a parser object
   parser = sax.make_parser()

   # Tell it what handler to use
   handler = SimpleHandler()
   parser.setContentHandler( handler )

   # Parse a file!
   parser.parse( 'hamlet.xml' )

For more information, consult the Python documentation, or the XML
HOWTO at https://pyxml.sourceforge.net/topics/howto/xml-howto.html.


Soporte DOM
-----------

The Document Object Model is a tree-based representation for an XML
document.  A top-level "Document" instance is the root of the tree,
and has a single child which is the top-level "Element" instance. This
"Element" has children nodes representing character data and any sub-
elements, which may have further children of their own, and so forth.
Using the DOM you can traverse the resulting tree any way you like,
access element and attribute values, insert and delete nodes, and
convert the tree back into XML.

El DOM es útil para modificar documentos XML, porque se puede crear un
árbol DOM, modificarlo añadiendo nuevos nodos o reordenando
subárboles, y luego producir un nuevo documento XML como salida.
También se puede construir un árbol DOM manualmente y convertirlo en
XML, lo que puede ser una forma más flexible de producir una salida
XML que simplemente escribir "<tag1>"..."</tag1>" un archivo.

The DOM implementation included with Python lives in the
"xml.dom.minidom" module.  It's a lightweight implementation of the
Level 1 DOM with support for XML namespaces.  The  "parse()" and
"parseString()" convenience functions are provided for generating a
DOM tree:

   from xml.dom import minidom
   doc = minidom.parse('hamlet.xml')

"doc" is a "Document" instance.  "Document", like all the other DOM
classes such as "Element" and "Text", is a subclass of the "Node" base
class.  All the nodes in a DOM tree therefore support certain common
methods, such as "toxml()" which returns a string containing the XML
representation of the node and its children.  Each class also has
special methods of its own; for example, "Element" and "Document"
instances have a method to find all child elements with a given tag
name. Continuing from the previous 2-line example:

   perslist = doc.getElementsByTagName( 'PERSONA' )
   print perslist[0].toxml()
   print perslist[1].toxml()

Para el archivo XML *Hamlet*, las líneas anteriores dan como
resultado:

   <PERSONA>CLAUDIUS, king of Denmark. </PERSONA>
   <PERSONA>HAMLET, son to the late, and nephew to the present king.</PERSONA>

El elemento raíz del documento está disponible como
"doc.documentElement", y sus hijos pueden modificarse fácilmente
borrando, añadiendo o eliminando nodos:

   root = doc.documentElement

   # Remove the first child
   root.removeChild( root.childNodes[0] )

   # Move the new first child to the end
   root.appendChild( root.childNodes[0] )

   # Insert the new first child (originally,
   # the third child) before the 20th child.
   root.insertBefore( root.childNodes[0], root.childNodes[20] )

Again, I will refer you to the Python documentation for a complete
listing of the different "Node" classes and their various methods.


Relación con PyXML
------------------

El Grupo de Interés Especial XML lleva un tiempo trabajando en código
Python relacionado con XML. Su distribución de código, llamada PyXML,
está disponible en las páginas web del SIG en
https://www.python.org/community/sigs/current/xml-sig. La distribución
de PyXML también utiliza el nombre de paquete "xml". Si has escrito
programas que utilizan PyXML, probablemente te preguntes sobre su
compatibilidad con el paquete 2.0 "xml".

La respuesta es que el paquete "xml" de Python 2.0 no es compatible
con PyXML, pero puede hacerse compatible instalando una versión
reciente de PyXML. Muchas aplicaciones pueden arreglárselas con el
soporte XML que se incluye en Python 2.0, pero las aplicaciones más
complicadas requerirán que se instale el paquete PyXML completo.
Cuando se instala, las versiones 0.6.0 o superiores de PyXML
sustituyen al paquete "xml" que se entrega con Python, y son un
estricto superconjunto del paquete estándar, añadiendo un montón de
características adicionales. Algunas de las características
adicionales de PyXML incluyen:

* 4DOM, una implementación completa de DOM de FourThought, Inc.

* El parser de validación xmlproc, escrito por Lars Marius Garshol.

* The "sgmlop" parser accelerator module, written by Fredrik Lundh.


Cambios en los módulos
======================

Lots of improvements and bugfixes were made to Python's extensive
standard library; some of the affected modules include "readline",
"ConfigParser", "cgi", "calendar", "posix", "readline", "xmllib",
"aifc", "chunk", "wave", "random", "shelve", and "nntplib".  Consult
the CVS logs for the exact patch-by-patch details.

Brian Gallew contributed OpenSSL support for the "socket" module.
OpenSSL is an implementation of the Secure Socket Layer, which
encrypts the data being sent over a socket.  When compiling Python,
you can edit "Modules/Setup" to include SSL support, which adds an
additional function to the "socket" module: "socket.ssl(socket,
keyfile, certfile)", which takes a socket object and returns an SSL
socket.  The "httplib" and "urllib" modules were also changed to
support "https://" URLs, though no one has implemented FTP or SMTP
over SSL.

The "httplib" module has been rewritten by Greg Stein to support
HTTP/1.1.

Backward compatibility with the 1.5 version of "httplib" is provided,
though using HTTP/1.1 features such as pipelining will require
rewriting code to use a different set of interfaces.

The "Tkinter" module now supports Tcl/Tk version 8.1, 8.2, or 8.3, and
support for the older 7.x versions has been dropped.  The Tkinter
module now supports displaying Unicode strings in Tk widgets. Also,
Fredrik Lundh contributed an optimization which makes operations like
"create_line" and "create_polygon" much faster, especially when using
lots of coordinates.

El módulo "curses" ha sido ampliado en gran medida, a partir de la
versión mejorada de Oliver Andrich, para proporcionar muchas funciones
adicionales de los curses ncurses y SYSV, como el color, el soporte de
conjuntos de caracteres alternativos, los pads y el soporte de ratón.
Esto significa que el módulo ya no es compatible con los sistemas
operativos que sólo tienen curses BSD, pero no parece haber ningún
sistema operativo actualmente mantenido que caiga en esta categoría.

Como se mencionó en la discusión anterior sobre el soporte Unicode de
la 2.0, la implementación subyacente de las expresiones regulares
proporcionadas por el módulo "re" ha sido cambiada. SRE, un nuevo
motor de expresiones regulares escrito por Fredrik Lundh y
parcialmente financiado por Hewlett Packard, soporta la comparación
con cadenas de 8 bits y cadenas Unicode.


Nuevos módulos
==============

Se han añadido varios módulos nuevos. Nos limitaremos a enumerarlos
con breves descripciones; consulte la documentación de la versión 2.0
para conocer los detalles de un módulo concreto.

* "atexit":  Para registrar las funciones que serán llamadas antes de
  que el intérprete de Python salga. El código que actualmente
  establece "sys.exitfunc" directamente debe cambiarse para usar el
  módulo "atexit" en su lugar, importando "atexit" y llamando a
  "atexit.register()" con la función a llamar al salir. (Contribución
  de Skip Montanaro)

* "codecs", "encodings", "unicodedata":  Added as part of the new
  Unicode support.

* "filecmp": Supersedes the old "cmp", "cmpcache" and "dircmp"
  modules, which have now become deprecated. (Contributed by Gordon
  MacMillan and Moshe Zadka.)

* "gettext": Este módulo proporciona soporte de internacionalización
  (I18N) y localización (L10N) para los programas de Python,
  proporcionando una interfaz a la biblioteca de catálogo de mensajes
  GNU gettext. (Integrado por Barry Warsaw, a partir de contribuciones
  separadas de Martin von Löwis, Peter Funk y James Henstridge)

* "linuxaudiodev": Support for the "/dev/audio" device on Linux, a
  twin to the existing "sunaudiodev" module. (Contributed by Peter
  Bosch, with fixes by Jeremy Hylton.)

* "mmap": Una interfaz para archivos mapeados en memoria tanto en
  Windows como en Unix. El contenido de un fichero puede ser mapeado
  directamente en memoria, en cuyo momento se comporta como una cadena
  mutable, por lo que su contenido puede ser leído y modificado.
  Incluso pueden pasarse a funciones que esperan cadenas ordinarias,
  como el módulo "re". (Contribución de Sam Rushing, con algunas
  extensiones de A.M. Kuchling)

* "pyexpat": An interface to the Expat XML parser. (Contributed by
  Paul Prescod.)

* "robotparser": Parse a "robots.txt" file, which is used for writing
  web spiders that politely avoid certain areas of a web site.  The
  parser accepts the contents of a "robots.txt" file, builds a set of
  rules from it, and can then answer questions about the fetchability
  of a given URL.  (Contributed by Skip Montanaro.)

* "tabnanny": Un módulo/script para comprobar el código fuente de
  Python en busca de sangrías ambiguas. (Contribuido por Tim Peters.)

* "UserString": A base class useful for deriving objects that behave
  like strings.

* "webbrowser": Un módulo que proporciona una forma independiente de
  la plataforma para lanzar un navegador web en una URL específica.
  Para cada plataforma, se prueban varios navegadores en un orden
  específico. El usuario puede modificar el navegador que se lanza
  estableciendo la variable de entorno *BROWSER*. (Originalmente
  inspirado por el parche de Eric S. Raymond a "urllib" que añadía una
  funcionalidad similar, pero el módulo final proviene de un código
  originalmente implementado por Fred Drake como
  "Tools/idle/BrowserControl.py", y adaptado para la biblioteca
  estándar por Fred)

* "_winreg": An interface to the Windows registry.  "_winreg" is an
  adaptation of functions that have been part of PythonWin since 1995,
  but has now been added to the core  distribution, and enhanced to
  support Unicode. "_winreg" was written by Bill Tutt and Mark
  Hammond.

* "zipfile": Un módulo para leer y escribir archivos con formato ZIP.
  Se trata de archivos producidos por **PKZIP** en DOS/Windows o
  **zip** en Unix, que no deben confundirse con los archivos con
  formato **gzip** (que son compatibles con el módulo "gzip")
  (Contribución de James C. Ahlstrom.)

* "imputil": A module that provides a simpler way for writing
  customized import hooks, in comparison to the existing "ihooks"
  module.  (Implemented by Greg Stein, with much discussion on python-
  dev along the way.)


Mejoras en IDLE
===============

IDLE es el IDE oficial de Python multiplataforma, escrito con Tkinter.
Python 2.0 incluye IDLE 0.6, que añade una serie de nuevas
características y mejoras. Una lista parcial:

* Mejoras y optimizaciones de la interfaz de usuario, especialmente en
  el área de resaltado de sintaxis y auto-indentación.

* El navegador de clases muestra ahora más información, como las
  funciones de nivel superior de un módulo.

* El ancho del tabulador es ahora una opción configurable por el
  usuario. Al abrir un archivo Python existente, IDLE detecta
  automáticamente las convenciones de sangría y se adapta.

* Ahora hay soporte para llamar a los navegadores en varias
  plataformas, utilizado para abrir la documentación de Python en un
  navegador.

* IDLE ahora tiene una línea de comandos, que es en gran medida
  similar al intérprete de Python vainilla.

* Se añadieron consejos de llamada en muchos lugares.

* Ahora IDLE puede instalarse como un paquete.

* En la ventana del editor, ahora hay una barra de líneas/columnas en
  la parte inferior.

* Tres nuevos comandos de teclado: Comprobar módulo ("Alt-F5"),
  Importar módulo ("F5") y Ejecutar script ("Ctrl-F5").


Módulos eliminados y obsoletos
==============================

A few modules have been dropped because they're obsolete, or because
there are now better ways to do the same thing.  The "stdwin" module
is gone; it was for a platform-independent windowing toolkit that's no
longer developed.

A number of modules have been moved to the "lib-old" subdirectory:
"cmp", "cmpcache", "dircmp", "dump",  "find", "grep", "packmail",
"poly", "util", "whatsound", "zmod".  If you have code which relies on
a module  that's been moved to "lib-old", you can simply add that
directory to "sys.path"   to get them back, but you're encouraged to
update any code that uses these modules.


Agradecimientos
===============

Los autores desean agradecer a las siguientes personas sus sugerencias
sobre varios borradores de este artículo: David Bolen, Mark Hammond,
Gregg Hauser, Jeremy Hylton, Fredrik Lundh, Detlef Lannert, Aahz
Maruch, Skip Montanaro, Vladimir Marangozov, Tobias Polzin, Guido van
Rossum, Neil Schemenauer y Russ Schmidt.
