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, \uHHHH, where HHHH is a 4-digit hexadecimal number from 0000 to FFFF. The existing \xHH 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.