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

Autor:
   Guido van Rossum

Este artículo explica las nuevas características de Python 3.0, en
comparación con 2.6. Python 3.0, también conocido como "Python 3000" o
"Py3K", es la primera versión *intentionally backwards incompatible*
de Python. Python 3.0 se lanzó el 3 de diciembre de 2008. Hay más
cambios que en una versión típica y más que son importantes para todos
los usuarios de Python. Sin embargo, después de digerir los cambios,
descubrirá que Python realmente no ha cambiado tanto; en general,
estamos solucionando principalmente molestias y defectos conocidos, y
eliminando una gran cantidad de viejas cosas.

Este artículo no intenta proporcionar una especificación completa de
todas las características nuevas, sino que intenta proporcionar una
visión general conveniente. Para obtener más información, se debe
consultar la documentación de Python 3.0 y/o los muchos PEP a los que
se hace referencia en el texto. Si se desea comprender la lógica
completa de implementación y diseño para una característica
determinada, los PEP suelen tener más detalles que la documentación
regular, pero téngase en cuenta que los PEP generalmente no se
mantienen actualizados una vez que una característica se ha
implementado completamente.

Debido a restricciones de tiempo, este documento no es tan completo
como debería haber sido. Como siempre para una nueva versión, el
archivo "Misc/NEWS" en la distribución de origen contiene una gran
cantidad de información detallada sobre cada pequeña cosa que se
cambió.


Escollos comunes
================

Esta sección contiene esos pequeños cambios que probablemente
generarán tropiezos si se está acostumbrado a Python 2.5.


*Print* es una función
----------------------

La declaración "print" se ha sustituido por una función "print()", con
argumentos de palabra clave para reemplazar la mayor parte de la
sintaxis especial de la antigua declaración "print" (**PEP 3105**).
Ejemplos:

   Old: print "The answer is", 2*2
   New: print("The answer is", 2*2)

   Old: print x,           # Trailing comma suppresses newline
   New: print(x, end=" ")  # Appends a space instead of a newline

   Old: print              # Prints a newline
   New: print()            # You must call the function!

   Old: print >>sys.stderr, "fatal error"
   New: print("fatal error", file=sys.stderr)

   Old: print (x, y)       # prints repr((x, y))
   New: print((x, y))      # Not the same as print(x, y)!

También se puede personalizar el separador entre ítems, por ejemplo:

   print("There are <", 2**32, "> possibilities!", sep="")

que genera:

   There are <4294967296> possibilities!

Nota:

* La función "print()" no soporta la característica "softspace" de la
  declaración "print" vieja. Por ejemplo, en Python 2.x "print "A\n",
  "B"" escribiría ""A\nB\n""; pero en Python 3.0, "print("A\n", "B")"
  escribe ""A\n B\n"".

* Inicialmente, te encontrarás escribiendo mucho la antigua "print x"
  en modo interactivo. ¡Es hora de volver a entrenar los dedos para
  escribir "print(x)" en su lugar!

* En el uso de la herramienta de conversión fuente-a-fuente "2to3",
  todos las declaraciones "print" son automáticamente convertidas a
  una llamada de la función "print()", por lo que en general esto no
  es un problema para proyectos más grandes.


Vistas e iteradores en lugar de listas
--------------------------------------

Algunas APIs bien conocidas no retornan más listas:

* Los métodos "dict" "dict.keys()", "dict.items()" y "dict.values()"
  retornan "vistas" en lugar de listas. Por ejemplo, esto no funciona
  más: "k = d.keys(); k.sort()". Se usa "k = sorted(d)" en su lugar
  (esto funciona también en Python 2.5 y es igual de eficiente).

* Además, los métodos "dict.iterkeys()", "dict.iteritems()" y
  "dict.itervalues()" ya no son compatibles.

* "map()" y "filter()" retornan iteradores. Si realmente se necesita
  una lista y las secuencias de entrada son todas de igual longitud,
  una solución rápida es envolver "map()" en "list()", por ejemplo
  "list(map(...))", pero una mejor solución es a menudo utilizar una
  lista por comprensión (especialmente cuando el código original
  utiliza "lambda"), o reescribir el código para que no necesite una
  lista en absoluto. Particularmente complicado es "map()" invocado
  para los efectos secundarios de la función; la transformación
  correcta es usar un bucle "for" normal (ya que crear una lista sería
  simplemente un desperdicio).

  Si las secuencias de entrada no tienen la misma longitud, "map()" se
  detendrá en la terminación de la más corta de las secuencias. Para
  una compatibilidad completa con "map()" de Python 2.x, también se
  envuelve las secuencias en "itertools.zip_longest()", por ejemplo
  "map(func, *sequences)" se convierte en "list(map(func,
  itertools.zip_longest(*sequences)))".

* "range()" ahora se comporta como "xrange()" solía comportarse,
  excepto que funciona con valores de tamaño arbitrario. Este último
  ya no existe.

* "zip()" ahora retorna un iterador.


Comparaciones de ordenamiento
-----------------------------

Python 3.0 ha simplificado las reglas para las comparaciones de
ordenamiento:

* Los operadores de comparaciones de ordenamiento ("<", "<",``'>``,
  ">") lanzan una excepción *TypeError* cuando los operandos no tienen
  un orden natural significativo. Por lo tanto, expresiones como "1 <
  ''", "0 > None" o "len <= len" ya no son válidas, y por ejemplo
  "Ninguno < Ninguno" lanza "TypeError" en lugar de retornar "False".
  Un corolario es que ordenar una lista heterogénea ya no tiene
  sentido -- todos los elementos deben ser comparables entre sí. Tener
  en cuenta que esto no se aplica a los operadores "==" y "!=": los
  objetos de diferentes tipos incomparables siempre se comparan
  desiguales entre sí.

* "builtin.sorted()" y "list.sort()" ya no aceptan el argumento *cmp*
  que proporciona una función de comparación. Utilice el argumento
  *key* en su lugar. N.B. los argumentos *key* y *reverse* ahora son
  "argumentos por palabra clave".

* La función "cmp()" debe tratarse como quitada, y el método especial
  "__cmp__()" ya no es compatible. Utilizar "__lt__()" para el
  ordenamiento, "__eq__()" con "__hash__()", y otras comparaciones
  costosas según sea necesario. (Si realmente se necesita la
  funcionalidad "cmp()", se puede utilizar la expresión "(a > b) - (a
  < b)" como el equivalente para "cmp(a, b)".)


Enteros
-------

* **PEP 237**: Esencialmente, "long" renombrado a "int". Es decir,
  solo hay un tipo integral incorporado, denominado "int"; pero se
  comporta sobre todo como el viejo tipo "long".

* **PEP 238**: Una expresión como "1/2" retorna un float. Utilizar
  "1//2" para obtener el comportamiento de truncamiento. (Esta última
  sintaxis ha existido durante años, al menos desde Python 2.2.)

* Se eliminó la constante "sys.maxint", ya que ya no hay un límite
  para el valor de los enteros. Sin embargo, "sys.maxsize" se puede
  utilizar como un entero mayor que cualquier lista práctica o índice
  de cadena de caracteres. Se ajusta al tamaño entero "natural" de la
  implementación y suele ser el mismo que "sys.maxint" en versiones
  anteriores de la misma plataforma (suponiendo las mismas opciones de
  compilación).

* El "repr()" de un entero largo ya no incluye la "L" final, por lo
  que el código que elimina incondicionalmente ese carácter cortará el
  último dígito en su lugar. (Utilizar "str()" en su lugar.)

* Los literales octales ya no usan la forma "0720"; úsese "0o720" en
  su lugar.


Texto vs. datos en lugar de unicode vs. 8 bits
----------------------------------------------

Todo lo que pensabas saber sobre datos binarios y Unicode ha cambiado.

* Python 3.0 utiliza los conceptos de *text* y *datos* (binarios) en
  lugar de cadenas de caracteres Unicode y cadenas de caracteres de 8
  bits. Todo el texto es Unicode; sin embargo el Unicode *codificado*
  se representa como datos binarios. El tipo utilizado para contener
  texto es "str", el tipo utilizado para contener datos es "bytes". La
  mayor diferencia con la situación 2.x es que cualquier intento de
  mezclar texto y datos en Python 3.0 lanza un "TypeError", mientras
  que si se mezclan cadenas Unicode y de 8 bits en Python 2.x,
  funcionaría si la cadena de 8 bits contuviera sólo bytes de 7 bits
  (ASCII), pero se obtendría un "UnicodeDecodeError" si contenía
  valores no ASCII. Este comportamiento específico del valor ha
  causado numerosas caras tristes a lo largo de los años.

* Como consecuencia de este cambio en la filosofía, prácticamente todo
  el código que utiliza Unicode, codificaciones o datos binarios muy
  probablemente tiene que cambiar. El cambio es para mejor, ya que en
  el mundo 2.x había numerosos errores que tenían que ver con la
  mezcla de texto codificado y sin codificar. Para estar preparado en
  Python 2.x, comienza a usar "unicode" para todo el texto sin
  codificar, y "str" solo para datos binarios o codificados. Luego ,
  la herramienta "2to3" hará la mayor parte del trabajo por ti.

* Ya no se puede utilizar literales "u"..."" para texto Unicode. Sin
  embargo, se debe usar literales "b"..."" para los datos binarios.

* Como los tipos "str" y "bytes" no se pueden mezclar, siempre se
  deben convertir explícitamente entre ellos. Utilizar "str.encode()"
  para pasar de "str" a "bytes", y "bytes.decode()" para pasar de
  "bytes" a "str". También se puede utilizar "bytes(s, encoding=...)"
  y "str(b, encoding=...)", respectivamente.

* Al igual que "str", el tipo "bytes" es inmutable. Hay un tipo
  *mutable* independiente para contener datos binarios almacenados en
  búfer, "bytearray". Casi todas las API que aceptan "bytes" también
  aceptan "bytearray". La API mutable se basa en "collections.
  MutableSequence".

* Todas las barras invertidas en literales de cadena de caracteres sin
  formato se interpretan literalmente. Esto significa que los escapes
  "'\U'" y "'\u'" en cadenas de caracteres sin formato no se tratan
  especialmente. Por ejemplo, "r'\u20ac'" es una cadena de 6
  caracteres en Python 3.0, mientras que en 2.6, "ur'\u20ac'" era el
  único carácter "euro". (Por supuesto, este cambio sólo afecta a los
  literales de cadena de caracteres sin formato; el carácter del euro
  es "'\u20ac'" en Python 3.0.)

* Se eliminó el tipo abstracto "basestring" incorporado. Se utiliza
  "str" en su lugar. Los tipos "str" y "bytes" no tienen suficiente
  funcionalidad en común para garantizar una clase base compartida. La
  herramienta "2to3" (ver más abajo) reemplaza cada aparición de
  "basestring" por "str".

* Los archivos abiertos como archivos de texto (todavía el modo
  predeterminado para "open()") siempre utilizan una codificación para
  asignar entre cadenas de caracteres(en memoria) y bytes (en disco).
  Los archivos binarios (abiertos con una "b" en el argumento modo)
  siempre utilizan bytes en la memoria. Esto significa que si un
  archivo se abre utilizando un modo o codificación incorrectos, es
  probable que la E/S falle ruidosamente, en lugar de producir datos
  incorrectos de forma silenciosa. También significa que incluso los
  usuarios de Unix tendrán que especificar el modo correcto (texto o
  binario) al abrir un archivo. Hay una codificación predeterminada
  dependiente de la plataforma, que en las plataformas Unix se puede
  establecer con la variable de entorno "LANG" (y a veces también con
  algunas otras variables de entorno relacionadas con la configuración
  regional específicas de la plataforma). En muchos casos, pero no en
  todos, el valor predeterminado del sistema es UTF-8; nunca se debe
  contar con este valor predeterminado. Cualquier aplicación que lea o
  escriba más que texto ASCII puro probablemente debería tener una
  manera de invalidar la codificación. Ya no es necesario utilizar las
  secuencias compatibles con la codificación en el módulo "codecs".

* Los valores iniciales de "sys.stdin", "sys.stdout" y "sys.stderr"
  ahora son archivos de texto solo unicode (es decir, son instancias
  de "io.TextIOBase"). Para leer y escribir datos de bytes con estas
  secuencias, se debe usar su atributo "io.TextIOBase.buffer".

* Los nombres de archivos son pasados y retornados de cadenas desde
  APIs como cadenas de caracteres (Unicode). Esto puede presentar
  problemas específicos de plataformas porque en algunas plataformas
  los nombres de archivos son cadenas de caracteres de bytes
  arbitrarios. (Por otro lado, en Windows los nombres de archivos son
  almacenados de forma nativa como Unicode.) Como solución
  alternativa, la mayoría de las APIs (por ejemplo "open()" y muchas
  otras funciones en el módulo "os") que toman nombres de archivos
  aceptan tanto objetos "bytes" como cadenas de caracteres, y algunas
  APIs tienen una forma de demandar por un valor de retorno "bytes".
  Por lo tanto, "os.listdir()" retorna una lista de instancias "bytes"
  si el argumento es una instancia "bytes", y "os.getcwdb()" retorna
  el directorio de trabajo actual como una instancia "bytes". Tener en
  cuenta que cuando "os.listdir()" retorna una lista de cadenas de
  caracteres, los nombres de archivo que no se pueden decodificar
  correctamente se omiten en lugar de lanzar "UnicodeError".

* Algunas APIs del sistema como "os.environ" y "sys.argv" también
  pueden presentar problemas cuando los bytes puestos a disposición
  por el sistema no son interpretables usando la codificación
  predeterminada. Probablemente el mejor abordaje sea asignando la
  variable "LANG" y volviendo a ejecutar el programa.

* **PEP 3138**: El "repr()" de una cadena de caracteres ya no escapa
  caracteres no ASCII. Sin embargo, todavía escapa caracteres de
  control caracteres y puntos de código con estado no imprimible en el
  estándar the Unicode.

* **PEP 3120**: La codificación de fuente predeterminada ahora es
  UTF-8.

* **PEP 3131**: Letras no ASCII ahora están permitidas en
  identificadores. (De todas maneras, la librería estándar permanece
  como sólo ASCII con la excepción de nombres de colaboradores en
  comentarios.)

* The "StringIO" and "cStringIO" modules are gone.  Instead, import
  the "io" module and use "io.StringIO" or "io.BytesIO" for text and
  data respectively.

* Ver también CÓMO (HOWTO) Unicode, que fue actualizado para Python
  3.0.


Descripción general de los cambios de sintaxis
==============================================

Esta sección brinda una descripción general breve de cada cambio
*sintáctico* en Python 3.0.


Nueva sintaxis
--------------

* **PEP 3107**: Argumento de función y anotaciones de valor retornado.
  Esto proporciona una forma estandarizada de anotar los parámetros y
  el valor retornado de una función. No hay semántica asociada a estas
  anotaciones, excepto que se pueden introspeccionar en tiempo de
  ejecución mediante el atributo "__annotations__". La intención es
  fomentar la experimentación a través de metaclases, decoradores o
  *frameworks*.

* **PEP 3102**: Argumentos de sólo palabra clave. Los parámetros con
  nombre que se producen después de "*args" en la lista de parámetros
  *deben* especificarse mediante la sintaxis de palabra clave en la
  llamada. También puede usarse apenas un "*" sólo en la lista de
  parámetros para indicar que no se acepta una lista de argumentos de
  longitud variable, pero se tiene argumentos de sólo palabra clave.

* Los argumentos de palabra clave se permiten después de la lista de
  clases base en una definición de clase. Esto lo usa la nueva
  convención para especificar una metaclase (consultar la sección
  siguiente), pero también se puede usar para otros fines, siempre y
  cuando la metaclase la admita.

* **PEP 3104**: Declaración "nonlocal". Utilizando "nonlocal x" ahora
  se puede asignar directamente a una variable en un entorno externo
  (pero no global). "nonlocal" es una nueva palabra reservada.

* **PEP 3132**: Desempaque iterable extendido. Ahora se puede escribir
  cosas como "a, b, *rest = some_sequence". E incluso "*rest, a =
  cosas". El objeto "rest" es siempre una lista (posiblemente vacía);
  el lado derecho puede ser cualquier iterable. Ejemplo:

     (a, *rest, b) = range(5)

  Esto asigna *a* a "0", *b* a "4", y *rest* a "[1, 2, 3]".

* Comprensiones por diccionario: "{k: v for k, v in cosas}" significa
  lo mismo que "dict(cosas)", pero es más flexible. (Esto es **PEP
  274** reivindicado. :-)

* Asignar los literales, por ejemplo, "{1, 2}". Tener en cuenta que
  "{}" es un diccionario vacío; utilizar "set()" para un conjunto
  vacío. También se admiten las comprensiones de conjunto; por
  ejemplo, "x for x in cosas" significa lo mismo que "set(cosas)",
  pero es más flexible.

* Nuevos octales literales, por ejemplo, "0o720" (ya en 2.6). Los
  octales literales viejos ("0720") se eliminaron.

* Nuevos literales binarios, por ejemplo, "0b1010" (ya en 2.6), y hay
  una nueva función incorporada correspondiente, "bin()".

* Los literales de bytes se introducen con un "b" o "B" delantero, y
  hay una nueva función incorporada correspondiente, "bytes()".


Sintaxis modificada
-------------------

* **PEP 3109** y **PEP 3134**: Nueva sintaxis de la instrucción
  "raise": "raise [*expr* [from *expr*]]". Ver a continuación.

* "as" y "with" ahora son palabras reservadas. (Desde 2.6, de hecho.)

* "True", "False" y "None" son palabras reservadas. (2.6 parcialmente
  estableció restricciones ya en "None".)

* Cambio de "except" *exc*, *var* a "except" *exc* "as" *var*.Ver
  **PEP 3110**.

* **PEP 3115**: Nueva sintaxis de metaclase. En lugar de:

     class C:
         __metaclass__ = M
         ...

  ahora se debe usar:

     class C(metaclass=M):
         ...

  Ya no se admite la variable de módulo global "__metaclass__". (Era
  una muleta para facilitar al valor predeterminado a las clases de
  estilo nuevo sin derivar todas las clases de "object".)

* Las listas por comprensión ya no admiten la forma sintáctica "[...
  for *var* in *item1*, *item2*, ...]". Utilizar "[... for*var* in
  (*item1*, *item2*, ...)]" en su lugar. También tener en cuenta que
  las listas por comprensión tienen semántica diferente: están más
  cerca del azúcar sintáctico para una expresión de generador dentro
  de un constructor "list()" y, en particular, las variables de
  control de bucle ya no se filtran en el ámbito circundante.

* La *elipsis* ("...") puede ser utilizada como una expresión atómica
  en cualquier lugar. (Previamente sólo estaba permitida en
  segmentos.) Asimismo, esto ahora *debe* ser escrito como "...".
  (Anteriormente, también podía ser escrito como ". . .", por un mero
  accidente de la gramática.)


Sintaxis eliminada
------------------

* **PEP 3113**: Desempaque de parámetros de tupla eliminados. Ya no se
  puede escribir "def foo(a, (b, c)): ...". Utilizar "def foo(a, b_c):
  b, c = b_c" en su lugar.

* Comillas invertidas eliminadas (usar "repr()" en su lugar).

* Eliminados "<>" (usar "!=" en su lugar).

* Palabra clave eliminada: "exec()" ya no es una palabra clave;
  continúa siendo una función. (Afortunadamente la sintaxis de la
  función también era aceptada en 2.x.) Asimismo, nótese que la
  "exec()" ya no toma un argumento de flujo; en lugar de "exec(f)" se
  puede utilizar "exec(f.read())".

* Literales enteros no admiten más "l" o "L" finales.

* Literales de cadena de caracteres no admiten más "u" or "U"
  iniciales.

* La sintaxis "from" *module* "import" "*" solo se permite en el nivel
  de módulo, ya no dentro de las funciones.

* La única sintaxis aceptable para *imports* relativos es "from
  .[*module*] import *name*". Todos los formularios "import" que no
  comienzan con "." son interpretados como *imports* absolutos

* Se eliminaron las clases clásicas.


Cambios ya presentes en Python 2.6
==================================

Dado que es de suponer que muchos usuarios saltan directamente de
Python 2.5 a Python 3.0, esta sección recuerda al lector nuevas
características que se diseñaron originalmente para Python 3.0 pero
que fueron llevadas hacia atrás a Python 2.6. Las secciones
correspondientes en Qué hay de nuevo en Python 2.6 deberían ser
consultadas para descripciones más largas.

* PEP 343: La sentencia 'with'.La declaración "with" ahora es una
  característica estándar y ya no necesita ser importada del
  "__future__". También puede revisarse Escribiendo gestores de
  contexto y El módulo contextlib.

* PEP 366: Importaciones relativas explícitas desde un módulo
  principal. Esto mejora la utilidad de opción "-m" cuando el módulo
  al que se hace referencia vive en un paquete.

* PEP 370: Directorio de site-packages por usuario.

* PEP 371: El paquete multiprocessing.

* PEP 3101: Formateo avanzado de cadena de caracteres. Nota: la
  descripción 2.6 menciona el método "format()" tanto para cadenas de
  caracteres 8 bits como de Unicode. En 3.0, solo el tipo "str"
  (cadenas de texto con compatibilidad con Unicode) admite este
  método; el tipo "bytes" no. El plan es a la larga convertir esta en
  la única API para el formato de cadena de caracteres y comenzar a
  dejar de utilizar el operador "%" en Python 3.1.

* PEP 3105: print como función. Esta ahora es una característica
  estándar y ya no necesita ser importada de "__future__". Más
  detalles fueron dados anteriormente.

* PEP 3110: Cambios en el manejo de excepciones. La sintaxis "except"
  *exc* "as" *var* ahora es estándar y "except" *exc*, *var* ya no es
  compatible. (Por supuesto, la parte "as" *var* sigue siendo
  opcional.)

* PEP 3112: Literales de bytes. La notación literal de cadena de
  caracteres "b"..."" (y sus variantes como "b'...'", "b"""..."""", y
  "br"..."") ahora genera un literal de tipo "bytes".

* PEP 3116: Nueva biblioteca de E/S. El módulo "io" ahora es la forma
  estándar de hacer E/S de archivos. La función incorporada "open()"
  ahora es un alias para "io.open()" y tiene argumentos de palabra
  clave adicionales *encoding*, *errors*, *newline* y *closefd*. Tener
  en cuenta también que un argumento *mode* inválido ahora lanza
  "ValueError", no "IOError". Se puede acceder al objeto de archivo
  binario subyacente a un objeto de archivo de texto como "f.buffer"
  (pero tener en cuenta que el objeto de texto mantiene un búfer de sí
  mismo para acelerar las operaciones de codificación y
  descodificación).

* PEP 3118: Protocolo revisado de la memoria intermedia. El antiguo
  "buffer()" incorporado ahora realmente se ha eliminado; el
  "memoryview()" incorporado nuevo proporciona (mayormente) una
  funcionalidad similar.

* PEP 3119: Clases base abstractas. El módulo "abc" y los ABC
  definidos en el módulo "collections" desempeñan un papel algo más
  destacado en el lenguaje ahora, y los tipos de colección
  incorporados como "dict" y "list" se ajustan a los ABCs de
  "collections.MutableMapping" y "collections.MutableSequence",
  respectivamente.

* PEP 3127: Soporte y sintaxis de literales enteros. Como se mencionó
  anteriormente, la nueva notación literal octal es la única admitida
  y se han agregado literales binarios.

* PEP 3129: Decoradores de clase.

* PEP 3141: Una jerarquía de tipos para los números. El módulo
  "numbers" es otro uso nuevo de ABCs, definiendo la "torre numérica"
  de Python. También tener en cuenta el nuevo módulo "fractions" que
  implementa "numbers.Rational".


Cambios de biblioteca
=====================

Debido a las limitaciones de tiempo, este documento no cubre
exhaustivamente los muy extensos cambios en la biblioteca estándar.
**PEP 3108** es la referencia para los principales cambios en la
biblioteca. Aquí hay una revisión de cápsula:

* Many old modules were removed.  Some, like "gopherlib" (no longer
  used) and "md5" (replaced by "hashlib"), were already deprecated by
  **PEP 4**.  Others were removed as a result of the removal of
  support for various platforms such as Irix, BeOS and Mac OS 9 (see
  **PEP 11**).  Some modules were also selected for removal in Python
  3.0 due to lack of use or because a better replacement exists.  See
  **PEP 3108** for an exhaustive list.

* The "bsddb3" package was removed because its presence in the core
  standard library has proved over time to be a particular burden for
  the core developers due to testing instability and Berkeley DB's
  release schedule.  However, the package is alive and well,
  externally maintained at
  https://www.jcea.es/programacion/pybsddb.htm.

* Algunos módulos fueron renombrados porque su antiguo nombre
  desobedeció **PEP 8**, o por varias otras razones. Aquí está la
  lista:

  +-------------------------+-------------------------+
  | Nombre anterior         | Nombre nuevo            |
  |=========================|=========================|
  | _winreg                 | winreg                  |
  +-------------------------+-------------------------+
  | ConfigParser            | configparser            |
  +-------------------------+-------------------------+
  | copy_reg                | copyreg                 |
  +-------------------------+-------------------------+
  | Queue                   | queue                   |
  +-------------------------+-------------------------+
  | SocketServer            | socketserver            |
  +-------------------------+-------------------------+
  | markupbase              | _markupbase             |
  +-------------------------+-------------------------+
  | repr                    | reprlib                 |
  +-------------------------+-------------------------+
  | test.test_support       | test.support            |
  +-------------------------+-------------------------+

* A common pattern in Python 2.x is to have one version of a module
  implemented in pure Python, with an optional accelerated version
  implemented as a C extension; for example, "pickle" and "cPickle".
  This places the burden of importing the accelerated version and
  falling back on the pure Python version on each user of these
  modules.  In Python 3.0, the accelerated versions are considered
  implementation details of the pure Python versions. Users should
  always import the standard version, which attempts to import the
  accelerated version and falls back to the pure Python version.  The
  "pickle" / "cPickle" pair received this treatment.  The "profile"
  module is on the list for 3.1.  The "StringIO" module has been
  turned into a class in the "io" module.

* Algunos módulos relacionados se han agrupado en paquetes y, por lo
  general, los nombres de submódulo se han simplificado. Los nuevos
  paquetes resultantes son:

  * "dbm" ("anydbm", "dbhash", "dbm", "dumbdbm", "gdbm", "whichdb").

  * "html" ("HTMLParser", "htmlentitydefs").

  * "http" ("httplib", "BaseHTTPServer", "CGIHTTPServer",
    "SimpleHTTPServer", "Cookie", "cookielib").

  * "tkinter" (todos los módulos relacionados con "Tkinter" excepto
    "turtle"). Al público objetivo de "turtle" no le interesa
    realmente "tkinter". También tener en cuenta que a partir de
    Python 2.6, la funcionalidad de "turtle" se ha mejorado
    considerablemente.

  * "urllib" ("urllib", "urllib2", "urlparse", "robotparse").

  * "xmlrpc" ("xmlrpclib", "DocXMLRPCServer", "SimpleXMLRPCServer").

Algunos otros cambios a los módulos de la biblioteca estándar, no
cubiertos por **PEP 3108**:

* Killed "sets".  Use the built-in "set()" class.

* Limpiado el módulo "sys": quitado "sys.exitfunc()",
  "sys.exc_clear()", "sys.exc_type", "sys.exc_value",
  "sys.exc_traceback". (Notar que "sys.last_type" etc. permanece.)

* Limpiado del tipo "array.array": los métodos "read()" y "write()" ya
  no están; usar "fromfile()" y "tofile()" en su lugar. Asimismo, the
  el código de tipo "'c'" para arreglo ya no está-- utilizar o bien
  "'b'" para bytes o "'u'" para caracteres Unicode.

* Limpieza del módulo "operator": quitados "sequenceIncludes()" y
  "isCallable()".

* Cleanup of the "thread" module: "acquire_lock()" and
  "release_lock()" are gone; use "acquire()" and "release()" instead.

* Limpieza del módulo "random": quitada la API "jumpahead()".

* The "new" module is gone.

* Las funciones "os.tmpnam()", "os.tempnam()" y "os.tmpfile()" se han
  eliminado en favor del módulo "tempfile".

* El módulo "tokenize" se ha cambiado para trabajar con bytes. El
  punto de entrada principal es ahora "tokenize.tokenize()", en lugar
  de generate_tokens.

* "string.letters" y sus amigos ("string.lowercase" y
  "string.uppercase") se han ido. Utilice "string.ascii_letters", etc.
  en su lugar. (El motivo de la eliminación es que "string.letters" y
  sus amigos tenían un comportamiento específico de la configuración
  regional, lo cual es una mala idea para "constantes" globales con
  nombres tan atractivos).

* Renombrado el módulo "__builtin__" a "builtins" (quitando los
  guiones bajos, agregando una 's'). La variable "__builtins__"
  encontrada en la mayoría de los espacios de nombres globales no
  tiene cambios. Para modificar un *builtin*, Se debería usar
  "builtins", no "__builtins__"!


**PEP 3101**: Un nuevo enfoque al formateo de cadena de caracteres
==================================================================

* Un nuevo sistema para operaciones de formateo de cadenas de
  caracteres incorporadas reemplaza el operador de formato de cadena
  de caracteres "%". (De todas maneras, el operador "%" sigue siento
  soportado; será obsoleto en Python 3.1 y quitado del lenguaje en
  algún momento más adelante.) Leer **PEP 3101** para la primicia
  completa.


Cambios a excepciones
=====================

Las APIs para lanzar y capturar excepciones se limpiaron y se
agregaron nuevas características poderosas:

* **PEP 352**: Todas las excepciones deben derivarse (directa o
  indirectamente) de "BaseException". Esta es la raíz de la jerarquía
  de excepciones. Esto no es nuevo como recomendación, pero el
  *requisito* de heredar de "BaseException" es nuevo. (Python 2.6 aún
  permitía que las clases clásicas se lanzaran, y no ponía ninguna
  restricción en lo que se podía capturar.) Como consecuencia, las
  excepciones de cadena de caracteres finalmente están verdaderamente
  y completamente muertas.

* Casi todas las excepciones deberían de hecho derivarse de
  "Exception"; "BaseException" sólo debe utilizarse como clase base
  para las excepciones que solo deben controlarse en el nivel
  superior, como "SystemExit" o "KeyboardInterrupt". El modismo
  recomendado para controlar todas las excepciones excepto esta última
  categoría es usar "except" "Exception".

* "StandardError" fue eliminado.

* Las excepciones ya no se comportan como secuencias. Utilizar el
  atributo "args" en su lugar.

* **PEP 3109**: Raising exceptions.  You must now use "raise
  *Exception*(*args*)" instead of "raise *Exception*, *args*".
  Additionally, you can no longer explicitly specify a traceback;
  instead, if you *have* to do this, you can assign directly to the
  "__traceback__" attribute (see below).

* **PEP 3110**: Atrapando excepciones. Ahora se debe usar "except
  *AlgunaExcepcion* como *variable*" en lugar de "except
  *AlgunaExcepcion*, *variable*". Además, la *variable* es
  específicamente eliminada cuando el bloque "except" se deja.

* **PEP 3134**: Exception chaining.  There are two cases: implicit
  chaining and explicit chaining.  Implicit chaining happens when an
  exception is raised in an "except" or "finally" handler block.  This
  usually happens due to a bug in the handler block; we call this a
  *secondary* exception.  In this case, the original exception (that
  was being handled) is saved as the "__context__" attribute of the
  secondary exception. Explicit chaining is invoked with this syntax:

     raise SecondaryException() from primary_exception

  (where *primary_exception* is any expression that produces an
  exception object, probably an exception that was previously caught).
  In this case, the primary exception is stored on the "__cause__"
  attribute of the secondary exception.  The traceback printed when an
  unhandled exception occurs walks the chain of "__cause__" and
  "__context__" attributes and prints a separate traceback for each
  component of the chain, with the primary exception at the top.
  (Java users may recognize this behavior.)

* **PEP 3134**: Exception objects now store their traceback as the
  "__traceback__" attribute.  This means that an exception object now
  contains all the information pertaining to an exception, and there
  are fewer reasons to use "sys.exc_info()" (though the latter is not
  removed).

* Algunos mensajes de excepción se mejoraron cuando Windows falla al
  cargar un módulo de extensión. Por ejemplo, "error code 193" ahora
  es "%1 is not a valid Win32 application". Las cadenas de caracteres
  ahora tratan con configuraciones regionales no inglesas.


Otros cambios diversos
======================


Operadores y métodos especiales
-------------------------------

* "!=" ahora retorna lo opuesto de "==", salvo que "==" retorne
  "NotImplemented".

* El concepto de "métodos independientes" fue quitado del lenguaje.
  Cuando se refiere a un método como atributo de clase, ahora se
  obtiene un objeto de función simple.

* "__getslice__()", "__setslice__()" y  "__delslice__()" se quitaron.
  La sintaxis "a[i:j]" ahora se traduce a "a.__getitem__(slice(i, j))"
  (o "__setitem__()" o "__delitem__()", cuando se utiliza como destino
  de asignación o eliminación, respectivamente).

* **PEP 3114**: El método estándar "next()" se ha renombrado como
  "__next__()".

* Los métodos especiales "__oct__()" y "__hex__()" se quitaron --
  "oct()" y "hex()" utilizan "__index__()" ahora para convertir el
  argumento a un entero.

* Soporte eliminado para "__members__" y "__methods__".

* The function attributes named "func_X" have been renamed to use the
  "__X__" form, freeing up these names in the function attribute
  namespace for user-defined attributes.  To wit, "func_closure",
  "func_code", "func_defaults", "func_dict", "func_doc",
  "func_globals", "func_name" were renamed to "__closure__",
  "__code__", "__defaults__", "__dict__", "__doc__", "__globals__",
  "__name__", respectively.

* "__nonzero__()" is now "__bool__()".


Incorporados
------------

* **PEP 3135**: Nuevo "super()". Ahora se puede invocar "super()" sin
  argumentos y (suponiendo que se encuentra en un método de instancia
  normal definido dentro de una declaración "class") se elegirá
  automáticamente la clase y la instancia correctas. Con argumentos,
  el comportamiento de "super()" no cambia.

* **PEP 3111**: "raw_input()" se renombró a "input()".  Es decir, la
  nueva función "input()" lee una línea de "sys.stdin" y la retorna
  con la línea final despojada. Lanza "EOFError" si la entrada se
  termina prematuramente. Para obtener el comportamiento anterior de
  "input()", utilice "eval(input())".

* Se añadió una nueva función incorporada "next()" para llamar al
  método "__next__()" sobre un objeto.

* La estrategia de redondeo de la función "round()" y el tipo de
  retorno han cambiado.  Los casos exactamente a mitad de camino ahora
  se redondean al resultado par más cercano en lugar de alejarse de
  cero. (Por ejemplo, "round(2.5)" ahora retorna ''2'' en lugar de
  "3".) "round(x[, n])" ahora delega en "x.__round__([n])" en lugar de
  retornar siempre un float. Por lo general, retorna un entero cuando
  se llama con un único argumento y un valor del mismo tipo que "x"
  cuando se llama con dos argumentos.

* Se movió "intern()" a "sys.intern()".

* Se eliminó: "apply()". En lugar de "apply(f, args)" se utiliza
  "f(*args)".

* Se eliminó "callable()". En lugar de "callable(f)" se puede utilizar
  "isinstance(f, collections.Callable)". La función
  "operator.isCallable()" también se quitó.

* Se eliminó "coerce()". Esta función ya no sirve para nada ahora que
  las clases clásicas se han quitado.

* Se eliminó "execfile()". En lugar de "execfile(fn)" utilizar
  "exec(open(fn).read())".

* Se eliminó el tipo "file". Se utiliza "open()". Ahora hay varios
  tipos diferentes de secuencias que se abren y pueden retornar en el
  módulo "io".

* Se eliminó "reduce()". Se puede utilizar "functools.reduce()" si es
  realmente necesario; de todas maneras, 99 por ciento del tiempo un
  bucle "for" explícito es más legible.

* Se eliminó "reload()". Se utiliza "imp.reload()".

* Se eliminó "dict.has_key()" -- se utiliza el operador "in" en su
  lugar.


Construcción y cambios a la API de C
====================================

Debido a restricciones de tiempo, aquí hay una *muy* incompleta lista
de cambios a la API de C.

* Se ha eliminado el soporte para varias plataformas, incluyendo pero
  no limitado a Mac OS 9, BeOS, RISCOS, Irix y Tru64.

* **PEP 3118**: Nueva API de búfer.

* **PEP 3121**: Inicialización y finalización de módulos de extensión.

* **PEP 3123**: Haciendo "PyObject_HEAD" conforme al estándar C.

* No más compatibilidad con API C para ejecución restringida.

* "PyNumber_Coerce()", "PyNumber_CoerceEx()", "PyMember_Get()", and
  "PyMember_Set()" C APIs are removed.

* La nueva API C "PyImport_ImportModuleNoBlock()", trabaja como
  "PyImport_ImportModule()" pero no bloqueará en el bloqueo de
  importación (en su lugar, retornará un error).

* Se renombró la conversión booleana de ranura de nivel C y el método:
  "nb_nonzero" ahora es "nb_bool".

* Removed "METH_OLDARGS" and "WITH_CYCLE_GC" from the C API.


Rendimiento
===========

El resultado neto de las generalizaciones 3.0 es que Python 3.0
ejecuta el punto de referencia *pystone* alrededor de 10% más lenta
que Python 2.5. Lo más probable es que la mayor causa sea la
eliminación de mayúsculas y minúsculas especiales para enteros
pequeños. Hay margen de mejora, ¡pero sucederá después de que se
publique 3.0!


Migración a Python 3.0
======================

Para migrar código Python 2.5 o 2.6 existente a Python 3.0, la mejor
estrategia es la siguiente:

* (Prerrequisito:) Comenzar con excelente cobertura de test.

* Migrar a Python 2.6. Esto no debería representar más trabajo que la
  migración promedio de Python 2.x a Python 2.(x+1). Asegurarse que
  todos los test pasen.

* (Todavía utilizando 2.6:) Activar el modificador de línea de
  comandos "-3". Esto habilita las advertencias sobre las
  características que se eliminarán (o cambiarán) en 3.0. Ejecutar el
  conjunto de pruebas de nuevo y corregir el código sobre el que se
  recibe advertencias hasta que no queden advertencias y todas las
  pruebas sigan pasando.

* Ejecutar el traductor de origen a origen "2to3" sobre el árbol de
  código fuente. (Consultar 2to3 --- Traducción automática de código
  de Python 2 a 3 para obtener más información sobre esta
  herramienta.) Ejecutar el resultado de la traducción en Python 3.0.
  Corregir manualmente los problemas restantes, solucionando problemas
  hasta que todos las pruebas vuelvan a pasar.

No se recomienda intentar escribir código fuente que se ejecute sin
cambios en Python 2.6 y 3.0; se tendría que usar un estilo de
codificación muy contorsionado, por ejemplo, evitando las sentencias
"print", metaclases y mucho más. Si se mantiene una biblioteca que
necesita soportar Python 2.6 y Python 3.0, el mejor enfoque es
modificar el paso 3 anterior editando la versión 2.6 del código fuente
y ejecutando el traductor "2to3" de nuevo, en lugar de editar la
versión 3.0 del código fuente.

Para migrar las extensiones C a Python 3.0, por favor ver Portar
módulos de extensión a Python 3.
