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

    ¡Hay <4294967296> posibilidades!

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

- Also, the `dict.iterkeys()`, `dict.iteritems()` and `dict.itervalues()` methods are no longer supported.

- `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()` now behaves like `xrange()` used to behave, except it works with values of arbitrary size. The latter no longer exists.

- `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í.

- `sorted()` and `list.sort()` no longer accept the cmp argument providing a comparison function. Use the key argument instead. N.B. the key and reverse arguments are now «keyword-only».

- The `cmp()` function should be treated as gone, and the `__cmp__()` special method is no longer supported. Use `__lt__()` for sorting, `__eq__()` with `__hash__()`, and other rich comparisons as needed. (If you really need the `cmp()` functionality, you could use the expression `(a > b) - (a < b)` as the equivalent for `cmp(a, b)`.)

### Enteros

- PEP 237: Essentially, `long` renamed to `int`. That is, there is only one built-in integral type, named `int`; but it behaves mostly like the old `long` type.

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

- The `sys.maxint` constant was removed, since there is no longer a limit to the value of integers. However, `sys.maxsize` can be used as an integer larger than any practical list or string index. It conforms to the implementation’s «natural» integer size and is typically the same as `sys.maxint` in previous releases on the same platform (assuming the same build options).

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

- As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text. To be prepared in Python 2.x, start using `unicode` for all unencoded text, and `str` for binary or encoded data only. Then the `2to3` tool will do most of the work for you.

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

- Like `str`, the `bytes` type is immutable. There is a separate mutable type to hold buffered binary data, `bytearray`. Nearly all APIs that accept `bytes` also accept `bytearray`. The mutable API is based on `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.)

- The built-in `basestring` abstract type was removed. Use `str` instead. The `str` and `bytes` types don’t have functionality enough in common to warrant a shared base class. The `2to3` tool (see below) replaces every occurrence of `basestring` with `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.)

- Los módulos `StringIO` and `cStringIO` ya no están. En su lugar, se importa el módulo the `io` y se usa `io.StringIO` o `io.BytesIO` para texto y datos respectivamente.

- 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: Function argument and return value annotations. This provides a standardized way of annotating a function’s parameters and return value. There are no semantics attached to such annotations except that they can be introspected at runtime using the `__annotations__` attribute. The intent is to encourage experimentation through metaclasses, decorators or 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:

      clase C:
      __metaclass__ = M
      ...

  ahora se debe usar:

      clase C(metaclase=M):
      ...

  The module-global `__metaclass__` variable is no longer supported. (It was a crutch to make it easier to default to new-style classes without deriving every class from `object`.)

- Las listas por comprensión ya no admiten la forma sintáctica `[... for var in item1, item2, ...]`. Utilizar `[... forvar 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. The `io` module is now the standard way of doing file I/O. The built-in `open()` function is now an alias for `io.open()` and has additional keyword arguments encoding, errors, newline and closefd. Also note that an invalid mode argument now raises `ValueError`, not `IOError`. The binary file object underlying a text file object can be accessed as `f.buffer` (but beware that the text object maintains a buffer of itself in order to speed up the encoding and decoding operations).

- PEP 3118: Protocolo revisado de la memoria intermedia. The old builtin `buffer()` is now really gone; the new builtin `memoryview()` provides (mostly) similar functionality.

- PEP 3119: Clases base abstractas. The `abc` module and the ABCs defined in the `collections` module plays a somewhat more prominent role in the language now, and built-in collection types like `dict` and `list` conform to the `collections.MutableMapping` and `collections.MutableSequence` ABCs, respectively.

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

- Se eliminaron muchos módulos antiguos. Algunos, como `gopherlib` (que ya no se utiliza) y `md5` (reemplazado por `hashlib`), ya estaban obsoletos en PEP 4. Otros se eliminaron como resultado de la eliminación del soporte para varias plataformas, como Irix, BeOS y Mac OS 9 (consulte PEP 11). También se seleccionaron algunos módulos para su eliminación en Python 3.0 debido a la falta de uso o porque existe un mejor reemplazo. Consulte PEP 3108 para obtener una lista exhaustiva.

- El paquete `bsddb3` fue eliminado porque su presencia en la biblioteca estándar principal ha demostrado con el tiempo ser una carga particular para los desarrolladores principales debido a la inestabilidad de las pruebas y al cronograma de lanzamiento de Berkeley DB. Sin embargo, el paquete está activo y bien, mantenido externamente en 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

- Un patrón común en Python 2.x es tener una versión de un módulo implementado en Python puro, con una versión acelerada opcional implementada como una extensión de C; por ejemplo, `pickle` y `cPickle`. Esto hace que la carga de importar la versión acelerada y recurrir a la versión Python pura recaiga sobre cada usuario de estos módulos. En Python 3.0, las versiones aceleradas se consideran detalles de implementación de las versiones Python puras. Los usuarios siempre deben importar la versión estándar, que intenta importar la versión acelerada y recurre a la versión Python pura. El par `pickle` / `cPickle` recibió este tratamiento. El módulo `profile` está en la lista para 3.1. El módulo `StringIO` se ha convertido en una clase en el módulo `io`.

- 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` (all `Tkinter`-related modules except `turtle`). The target audience of `turtle` doesn’t really care about `tkinter`. Also note that as of Python 2.6, the functionality of `turtle` has been greatly enhanced.

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

- Quitado `sets`. Usar la clase incorporada `set()`.

- Cleanup of the `sys` module: removed `sys.exitfunc()`, `sys.exc_clear()`, `sys.exc_type`, `sys.exc_value`, `sys.exc_traceback`. (Note that `sys.last_type` etc. remain.)

- Cleanup of the `array.array` type: the `read()` and `write()` methods are gone; use `fromfile()` and `tofile()` instead. Also, the `'c'` typecode for array is gone – use either `'b'` for bytes or `'u'` for Unicode characters.

- Cleanup of the `operator` module: removed `sequenceIncludes()` and `isCallable()`.

- Limpieza del módulo `thread`: `acquire_lock()` y `release_lock()` han desaparecido; utilice `acquire()` y `release()` en su lugar.

- Cleanup of the `random` module: removed the `jumpahead()` API.

- El módulo `new` ya no está.

- The functions `os.tmpnam()`, `os.tempnam()` and `os.tmpfile()` have been removed in favor of the `tempfile` module.

- 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` and its friends (`string.lowercase` and `string.uppercase`) are gone. Use `string.ascii_letters` etc. instead. (The reason for the removal is that `string.letters` and friends had locale-specific behavior, which is a bad idea for such attractively named global «constants».)

- Renamed module `__builtin__` to `builtins` (removing the underscores, adding an “s”). The `__builtins__` variable found in most global namespaces is unchanged. To modify a builtin, you should use `builtins`, not `__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` was removed.

- Exceptions no longer behave as sequences. Use the `args` attribute instead.

- PEP 3109: Generación de excepciones. Ahora debe utilizar `raise Exception(args)` en lugar de `raise Exception, args`. Además, ya no puede especificar explícitamente un seguimiento; en su lugar, si desea hacerlo, puede asignarlo directamente al atributo `__traceback__` (consulte a continuación).

- 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: encadenamiento de excepciones. Existen dos casos: encadenamiento implícito y encadenamiento explícito. El encadenamiento implícito se produce cuando se genera una excepción en un bloque de controlador `except` o `finally`. Esto suele ocurrir debido a un error en el bloque de controlador; lo llamamos excepción secondary. En este caso, la excepción original (que se estaba manejando) se guarda como el atributo `__context__` de la excepción secundaria. El encadenamiento explícito se invoca con esta sintaxis:

      generar SecondaryException() desde primary_exception

  (donde primary_exception es cualquier expresión que produce un objeto de excepción, probablemente una excepción que se detectó previamente). En este caso, la excepción principal se almacena en el atributo `__cause__` de la excepción secundaria. El seguimiento que se imprime cuando se produce una excepción no controlada recorre la cadena de atributos `__cause__` y `__context__` e imprime un seguimiento independiente para cada componente de la cadena, con la excepción principal en la parte superior. (Los usuarios de Java pueden reconocer este comportamiento).

- PEP 3134: Los objetos de excepción ahora almacenan su seguimiento como atributo `__traceback__`. Esto significa que un objeto de excepción ahora contiene toda la información relacionada con una excepción y hay menos razones para usar `sys.exc_info()` (aunque este último no se ha eliminado).

- 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__()` and `__delslice__()` were killed. The syntax `a[i:j]` now translates to `a.__getitem__(slice(i, j))` (or `__setitem__()` or `__delitem__()`, when used as an assignment or deletion target, respectively).

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

- The `__oct__()` and `__hex__()` special methods are removed – `oct()` and `hex()` use `__index__()` now to convert the argument to an integer.

- Removed support for `__members__` and `__methods__`.

- Los atributos de función denominados `func_X` se han renombrado para utilizar el formato `__X__`, lo que libera estos nombres en el espacio de nombres de atributos de función para los atributos definidos por el usuario. Es decir, `func_closure`, `func_code`, `func_defaults`, `func_dict`, `func_doc`, `func_globals`, `func_name` se renombraron a `__closure__`, `__code__`, `__defaults__`, `__dict__`, `__doc__`, `__globals__`, `__name__`, respectivamente.

- `__nonzero__()` ahora es `__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()` was renamed to `input()`. That is, the new `input()` function reads a line from `sys.stdin` and returns it with the trailing newline stripped. It raises `EOFError` if the input is terminated prematurely. To get the old behavior of `input()`, use `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.

- Moved `intern()` to `sys.intern()`.

- Removed: `apply()`. Instead of `apply(f, args)` use `f(*args)`.

- Removed `callable()`. Instead of `callable(f)` you can use `isinstance(f, collections.Callable)`. The `operator.isCallable()` function is also gone.

- Removed `coerce()`. This function no longer serves a purpose now that classic classes are gone.

- Removed `execfile()`. Instead of `execfile(fn)` use `exec(open(fn).read())`.

- Removed the `file` type. Use `open()`. There are now several different kinds of streams that open can return in the `io` module.

- Removed `reduce()`. Use `functools.reduce()` if you really need it; however, 99 percent of the time an explicit `for` loop is more readable.

- Removed `reload()`. Use `imp.reload()`.

- Removed. `dict.has_key()` – use the `in` operator instead.

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

- Las API C `PyNumber_Coerce()`, `PyNumber_CoerceEx()`, `PyMember_Get()`, y `PyMember_Set()` se eliminan.

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

- Se eliminó `METH_OLDARGS` y `WITH_CYCLE_GC` de la API C.

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

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

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

2. (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.

3. Ejecute el traductor de código fuente a código fuente `2to3` sobre su árbol de código fuente. Ejecute el resultado de la traducción en Python 3.0. Corrija manualmente los problemas restantes hasta que se aprueben todas las pruebas nuevamente.

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.