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.

Lea el resto de **PEP 1** para conocer los detalles del proceso
editorial, el estilo y el formato de PEP. Los PEP se guardan en el
árbol CVS de Python en SourceForge, aunque no son parte de la
distribución de Python 2.0, y también están disponibles en formato
HTML en https://peps.python.org/. A partir de septiembre de 2000,
existen 25 PEP, que van desde **PEP 201**, "Iteración en sincronía",
hasta PEP 225, "Operadores por elementos y por objetos".


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.

En el código fuente de Python, las cadenas Unicode se escriben como
"u"string"". Se pueden escribir caracteres Unicode arbitrarios
utilizando una nueva secuencia de escape, "\u*HHHH*", donde *HHHH* es
un número hexadecimal de 4 dígitos de 0000 a FFFF. También se puede
utilizar la secuencia de escape existente "\x*HH*", y se pueden
utilizar escapes octales para caracteres hasta U+01FF, que se
representa mediante "\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* es una clase que admite la decodificación de la
  entrada de un flujo. *stream_reader(file_obj)* devuelve un objeto
  que admite los métodos "read()", "readline()" y "readlines()". Todos
  estos métodos traducirán a partir de la codificación dada y
  devolverán cadenas Unicode.

* De manera similar, *stream_writer* es una clase que admite la
  codificación de la salida en una secuencia.
  *stream_writer(file_obj)* devuelve un objeto que admite los métodos
  "write()" y "writelines()". Estos métodos esperan cadenas Unicode y
  las traducen a la codificación dada en la salida.

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:

   sublista = [ s para s en L si cadena.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".

La lista completa de operadores de asignación admitidos es "+=", "-=",
"*=", "/=", "%=", "**=", "&=", "|=", "^=", ">>=" y "<<=". Las clases
de Python pueden anular los operadores de asignación aumentados
definiendo métodos denominados "__iadd__()", "__isub__()", etc. Por
ejemplo, la siguiente clase "Number" almacena un número y admite el
uso de += para crear una nueva instancia con un valor incrementado.

   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

El método especial "__iadd__()" se llama con el valor del incremento y
debe devolver una nueva instancia con un valor modificado
apropiadamente; este valor de retorno está vinculado como el nuevo
valor de la variable en el lado izquierdo.

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

Hasta ahora, la funcionalidad de manipulación de cadenas estaba en el
módulo "string", que normalmente era una interfaz para el módulo
"strop" escrito en C. La incorporación de Unicode planteó una
dificultad para el módulo "strop", porque todas las funciones debían
reescribirse para aceptar cadenas de 8 bits o Unicode. Para funciones
como "string.replace()", que acepta 3 cadenas como argumentos, eso
significa ocho permutaciones posibles y, en consecuencia, un código
complicado.

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.

Dos métodos que no tienen paralelo en versiones anteriores a la 2.0,
aunque existieron en JPython durante bastante tiempo, son
"startswith()" y "endswith()". "s.startswith(t)" es equivalente a
"s[:len(t)] == t", mientras que "s.endswith(t)" es equivalente a
"s[-len(t):] == t".

Otro método que merece una mención especial es el "join()". El método
"join()" de una cadena recibe un parámetro, una secuencia de cadenas,
y es equivalente a la función "string.join()" del antiguo módulo
"string", con los argumentos invertidos. En otras palabras, el
"s.join(seq)" es equivalente al antiguo "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:

   instancia = SomeClass()
   instancia.myself = instancia

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

Una nueva sintaxis hace que sea más conveniente llamar a una función
dada con una tupla de argumentos y/o un diccionario de argumentos de
palabras clave. En Python 1.5 y anteriores, se usaba la función
incorporada "apply()": "apply(f, args, kw)" llama a la función "f()"
con la tupla de argumentos *args* y los argumentos de palabras clave
en el diccionario *kw*. "apply()" es lo mismo en 2.0, pero gracias a
un parche de Greg Ewing, "f(*args, **kw)" es una forma más corta y
clara de lograr el mismo efecto. Esta sintaxis es simétrica con la
sintaxis para definir funciones:

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

Ahora, la salida de la sentencia "print" puede dirigirse a un objeto
similar a un archivo si se sigue "print" con ">> file", de forma
similar al operador de redirección de los shells de Unix. Antes, se
tenía que utilizar el método "write()" del objeto similar a un
archivo, que carece de la comodidad y la simplicidad de "print", o se
podía asignar un nuevo valor a "sys.stdout" y luego restaurar el valor
anterior. Para enviar la salida al error estándar, es mucho más fácil
escribir esto:

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

Anteriormente no había forma de implementar una clase que anulara el
operador "in" incorporado de Python e implementara una versión
personalizada. "obj in seq" devuelve verdadero si *obj* está presente
en la secuencia *seq*; Python calcula esto simplemente probando cada
índice de la secuencia hasta que se encuentre *obj* o "IndexError".
Moshe Zadka contribuyó con un parche que agrega un método mágico
"__contains__()" para proporcionar una implementación personalizada
para "in". Además, los nuevos objetos incorporados escritos en C
pueden definir lo que "in" significa para ellos a través de una nueva
ranura en el protocolo de secuencia.

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)

La comparación "a==b" devuelve verdadero, porque las dos estructuras
de datos recursivas son isomorfas. Consulte el hilo "trashcan y PR#7"
en los archivos de abril de 2000 de la lista de correo python-dev para
ver la discusión que condujo a esta implementación y algunos enlaces
relevantes útiles. Tenga en cuenta que las comparaciones ahora también
pueden generar excepciones. En versiones anteriores de Python, una
operación de comparación como "cmp(a,b)" siempre produciría una
respuesta, incluso si un método "__cmp__()" definido por el usuario
encontrara un error, ya que la excepción resultante simplemente se
tragaría silenciosamente.

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.

Las funciones "int()" y "long()" ahora aceptan un parámetro "base"
opcional cuando el primer argumento es una cadena. "int('123', 10)"
devuelve 123, mientras que "int('123', 16)" devuelve 291. "int(123,
16)" genera una excepción "TypeError" con el mensaje "no se puede
convertir una cadena con una base explícita".

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.

Los diccionarios tienen un nuevo método extraño, "setdefault(key,
default)", que se comporta de manera similar al método "get()"
existente. Sin embargo, si falta la clave, "setdefault()" devuelve el
valor de *default* como lo haría "get()" y también lo inserta en el
diccionario como el valor de *key*. Por lo tanto, las siguientes
líneas de código:

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

Las versiones anteriores de estos métodos eran más indulgentes porque
utilizaban una función antigua en la interfaz C de Python para
analizar sus argumentos; la versión 2.0 los moderniza para utilizar
"PyArg_ParseTuple()", la función de análisis de argumentos actual, que
proporciona mensajes de error más útiles y trata las llamadas de
múltiples argumentos como errores. Si es absolutamente necesario
utilizar la versión 2.0 pero no puede corregir su código, puede editar
"Objects/listobject.c" y definir el símbolo de preprocesador
"NO_STRICT_LIST_APPEND" para preservar el comportamiento anterior;
esto no se recomienda.

Algunas de las funciones del módulo "socket" siguen siendo indulgentes
en este sentido. Por ejemplo, "socket.connect( ('hostname', 25) )" es
la forma correcta, ya que pasa una tupla que representa una dirección
IP, pero "socket.connect('hostname', 25)" también funciona.
"socket.connect_ex" y "socket.bind" son igualmente fáciles de usar.
2.0alpha1 restringió estas funciones, pero debido a que la
documentación en realidad usaba la forma de argumentos múltiples
errónea, muchas personas escribieron código que rompería con la
verificación más estricta. GvR retiró los cambios ante la reacción del
público, por lo que para el módulo "socket", la documentación se
corrigió y la forma de argumentos múltiples simplemente se marcó como
obsoleta; *will* se ajustará nuevamente en una futura versión de
Python.

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.

Se ha trabajado un poco para que los números enteros y los números
enteros largos sean un poco más intercambiables. En 1.5.2, se agregó
soporte para archivos grandes para Solaris, para permitir la lectura
de archivos mayores a 2 GiB; esto hizo que el método "tell()" de
objetos de archivo devolviera un número entero largo en lugar de un
número entero regular. Algunos códigos restaban dos desplazamientos de
archivo e intentaban usar el resultado para multiplicar una secuencia
o cortar una cadena, pero esto generaba un "TypeError". En 2.0, los
números enteros largos se pueden usar para multiplicar o cortar una
secuencia, y se comportará como esperaría intuitivamente; "3L * 'abc'"
produce 'abcabcabc' y "(0,1,2,3)[2L:4L]" produce (2,3). Los números
enteros largos también se pueden usar en varios contextos donde
anteriormente solo se aceptaban números enteros, como en el método
"seek()" de objetos de archivo y en los formatos admitidos por el
operador "%" ("%d", "%i", "%x", etc.). Por ejemplo, ""%d" % 2L**64"
producirá la cadena "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.

Ahora, al tomar el "repr()" de un float, se utiliza una precisión de
formato diferente a la de "str()". "repr()" utiliza la cadena de
formato "%.17g" para "sprintf()" de C, mientras que "str()" utiliza
"%.12g" como antes. El efecto es que "repr()" puede mostrar
ocasionalmente más decimales que "str()" para ciertos números. Por
ejemplo, el número 8.1 no se puede representar exactamente en binario,
por lo que "repr(8.1)" es "'8.0999999999999996'", mientras que
str(8.1) es "'8.1'".

Se ha eliminado la opción de línea de comandos "-X", que convertía
todas las excepciones estándar en cadenas en lugar de clases; ahora
las excepciones estándar siempre serán clases. El módulo "exceptions"
que contiene las excepciones estándar se tradujo de Python a un módulo
C integrado, escrito por Barry Warsaw y 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".

La esperada reestructuración de malloc de Vladimir Marangozov se
completó para facilitar que el intérprete de Python use un asignador
personalizado en lugar del "malloc()" estándar de C. Para consultar la
documentación, lea los comentarios en "Include/pymem.h" y
"Include/objimpl.h". Para consultar las extensas discusiones durante
las cuales se elaboró ​​la interfaz, consulte los archivos web de las
listas 'patches' y 'python-dev' en 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}".

Se agregaron tres nuevas funciones de conveniencia destinadas a
agregar constantes al diccionario de un módulo en el momento de
inicialización del módulo: "PyModule_AddObject()",
"PyModule_AddIntConstant()" y "PyModule_AddStringConstant()". Cada una
de estas funciones toma un objeto de módulo, una cadena C terminada en
cero que contiene el nombre que se agregará y un tercer argumento para
el valor que se asignará al nombre. Este tercer argumento es,
respectivamente, un objeto Python, un long C o una cadena C.

Se agregó una API contenedora para los controladores de señales de
estilo Unix. "PyOS_getsig()" obtiene un controlador de señales y
"PyOS_setsig()" establecerá un nuevo controlador.


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 para utilidades de distribución, dirigido por Greg Ward, ha
creado Distutils, un sistema para facilitar enormemente 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, instalar un
módulo Python desde el código fuente requerirá los mismos pasos:
primero, simplemente hay que descomprimir el archivo tarball o zip y
ejecutar ""python setup.py install"". La plataforma se detectará
automáticamente, se reconocerá el compilador, se compilarán los
módulos de extensión de C y se instalará la distribución en el
directorio adecuado. 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 compilación de la instalación,
compilando o instalando en directorios que no sean los
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 incluía un analizador XML simple en forma del módulo
"xmllib", aportado por Sjoerd Mullender. Desde el lanzamiento de la
versión 1.5.2, se han vuelto comunes dos interfaces diferentes para
procesar XML: SAX2 (versión 2 de la API simple para XML) proporciona
una interfaz basada en eventos con algunas similitudes con "xmllib", y
DOM (Document Object Model) proporciona una interfaz basada en
árboles, transformando un documento XML en un árbol de nodos que se
puede recorrer y modificar. Python 2.0 incluye una interfaz SAX2 y una
interfaz DOM simplificada como parte del paquete "xml". Aquí daremos
una breve descripción general de estas nuevas interfaces; consulte la
documentación de Python o el código fuente para obtener detalles
completos. El SIG de XML de Python también está trabajando en una
documentación mejorada.


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

SAX define una interfaz controlada por eventos para analizar XML. Para
utilizar SAX, debe escribir una clase controladora de SAX. Las clases
controladoras heredan de varias clases proporcionadas por SAX y
reemplazan varios métodos que luego llamará el analizador XML. Por
ejemplo, los métodos "startElement()" y "endElement()" se llaman para
cada etiqueta de inicio y fin que encuentre el analizador, el método
"characters()" se llama para cada fragmento de datos de caracteres, y
así sucesivamente.

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' )

Para más información, consulte la documentación de Python o el XML
HOWTO en https://pyxml.sourceforge.net/topics/howto/xml-howto.html.


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

El modelo de objetos de documento es una representación basada en
árboles para un documento XML. Una instancia "Document" de nivel
superior es la raíz del árbol y tiene un único elemento secundario que
es la instancia "Element" de nivel superior. Este "Element" tiene
nodos secundarios que representan datos de caracteres y cualquier
subelemento, que puede tener otros elementos secundarios propios, y
así sucesivamente. Con el DOM, puede recorrer el árbol resultante de
la forma que desee, acceder a los valores de los elementos y
atributos, insertar y eliminar nodos y convertir el árbol nuevamente
en 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.

La implementación del DOM incluida con Python se encuentra en el
módulo "xml.dom.minidom". Es una implementación liviana del DOM de
nivel 1 con soporte para espacios de nombres XML. Las funciones de
conveniencia "parse()" y "parseString()" se proporcionan para generar
un árbol DOM:

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

"doc" es una instancia de "Document". "Document", al igual que todas
las demás clases DOM como "Element" y "Text", es una subclase de la
clase base "Node". Por lo tanto, todos los nodos de un árbol DOM
admiten ciertos métodos comunes, como "toxml()", que devuelve una
cadena que contiene la representación XML del nodo y sus hijos. Cada
clase también tiene sus propios métodos especiales; por ejemplo, las
instancias "Element" y "Document" tienen un método para encontrar
todos los elementos secundarios con un nombre de etiqueta determinado.
Continuando con el ejemplo anterior de 2 líneas:

   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>CLAUDIO, rey de Dinamarca. </PERSONA>
   <PERSONA>HAMLET, hijo del difunto rey y sobrino del actual.</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

   # Eliminar el primer hijo
   root.removeChild( root.childNodes[0] )

   # Mover el nuevo primer hijo al final
   root.appendChild( root.childNodes[0] )

   # Insertar el nuevo primer hijo (originalmente,
   # el tercer hijo) antes del hijo número 20.
   root.insertBefore( root.childNodes[0], root.childNodes[20] )

Una vez más, te remito a la documentación de Python para obtener una
lista completa de las diferentes clases "Node" y sus diversos métodos.


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.

* El módulo acelerador del parser "sgmlop", escrito por Fredrik Lundh.


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

Se realizaron muchas mejoras y correcciones de errores en la extensa
biblioteca estándar de Python; algunos de los módulos afectados
incluyen "readline", "ConfigParser", "cgi", "calendar", "posix",
"readline", "xmllib", "aifc", "chunk", "wave", "random", "shelve" y
"nntplib". Consulte los registros CVS para obtener detalles exactos de
cada parche.

Brian Gallew contribuyó con la compatibilidad con OpenSSL para el
módulo "socket". OpenSSL es una implementación de la capa de sockets
seguros, que cifra los datos que se envían a través de un socket. Al
compilar Python, puede editar "Modules/Setup" para incluir
compatibilidad con SSL, lo que agrega una función adicional al módulo
"socket": "socket.ssl(socket, keyfile, certfile)", que toma un objeto
de socket y devuelve un socket SSL. Los módulos "httplib" y "urllib"
también se modificaron para admitir las URL de "https://", aunque
nadie ha implementado FTP o SMTP sobre SSL.

Greg Stein ha reescrito el módulo "httplib" para admitir HTTP/1.1.

Se proporciona compatibilidad con versiones anteriores de la versión
1.5 de "httplib", aunque el uso de funciones HTTP/1.1 como la
canalización requerirá reescribir el código para usar un conjunto
diferente de interfaces.

El módulo "Tkinter" ahora es compatible con las versiones 8.1, 8.2 u
8.3 de Tcl/Tk y se ha eliminado la compatibilidad con las versiones
7.x anteriores. El módulo Tkinter ahora es compatible con la
visualización de cadenas Unicode en widgets Tk. Además, Fredrik Lundh
contribuyó con una optimización que hace que operaciones como
"create_line" y "create_polygon" sean mucho más rápidas, especialmente
cuando se utilizan muchas coordenadas.

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":  Añadidos como parte del nuevo
  soporte de Unicode.

* "filecmp": Sustituye a los antiguos módulos "cmp", "cmpcache" y
  "dircmp", que han quedado obsoletos. (Contribución de Gordon
  MacMillan y 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": Soporte para el dispositivo "/dev/audio" en Linux,
  un gemelo del módulo existente "sunaudiodev". (Contribuido por Peter
  Bosch, con correcciones de 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": Una interfaz para el analizador XML de Expat.
  (Contribuido por Paul Prescod.)

* "robotparser": Analiza un archivo "robots.txt", que se utiliza para
  escribir arañas web que evitan amablemente ciertas áreas de un sitio
  web. El analizador acepta el contenido de un archivo "robots.txt",
  construye un conjunto de reglas a partir de él y puede responder a
  preguntas sobre la capacidad de búsqueda de una URL determinada.
  (Contribución de 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": Una clase base útil para derivar objetos que se
  comportan como cadenas.

* "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": Una interfaz para el registro de Windows. "_winreg" es
  una adaptación de las funciones que han formado parte de PythonWin
  desde 1995, pero ahora se ha añadido a la distribución principal, y
  se ha mejorado para soportar Unicode. "_winreg" fue escrito por Bill
  Tutt y 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": Un módulo que proporciona una forma más sencilla de
  escribir ganchos de importación personalizados, en comparación con
  el módulo "ihooks" existente. (Implementado por Greg Stein, con
  mucha discusión en python-dev a lo largo del camino)


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

Se han eliminado algunos módulos porque son obsoletos, o porque ahora
hay mejores formas de hacer lo mismo. El módulo "stdwin" ha
desaparecido; era para un conjunto de herramientas de ventanas
independientes de la plataforma que ya no se desarrolla.

Se han movido varios módulos al subdirectorio "lib-old": "cmp",
"cmpcache", "dircmp", "dump", "find", "grep", "packmail", "poly",
"util", "whatsound", "zmod". Si tiene código que depende de un módulo
que se ha movido a "lib-old", puede simplemente agregar ese directorio
a "sys.path" para recuperarlo, pero se le recomienda que actualice
cualquier código que use estos módulos.


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.
