# Novedades de Python 3.4

Autor

  R. David Murray <rdmurray@bitdance.com> (Editor)

Este artículo explica las nuevas características de Python 3.4, en comparación con la 3.3. Python 3.4 se publicó el 16 de marzo de 2014. Para obtener todos los detalles, consulte el changelog.

Ver también

PEP 429 – Calendario de lanzamiento de Python 3.4

## Resumen – Puntos destacados del lanzamiento

Nuevas características de sintaxis:

- En Python 3.4 no se han añadido nuevas características sintácticas.

Otras novedades:

- pip debe estar siempre disponible (PEP 453).

- Los descriptores de archivo recién creados no son heredables (PEP 446).

- opción de línea de comandos para modo aislado (bpo-16499).

- mejoras en el manejo de códecs que no son codificaciones de texto (múltiples problemas).improvements>

- Un tipo de ModuleSpec para el sistema de importación (PEP 451). (Afecta a los autores de los importadores)

- El formato `marshal` se ha hecho más compacto y eficiente (bpo-16475).

Nuevos módulos de la biblioteca:

- `asyncio`: Nueva API provisional para IO asíncrona (PEP 3156).

- `ensurepip`: Bootstrapping the pip installer (PEP 453).

- `enum`: Soporte para tipos de enumeración (PEP 435).

- `pathlib`: Rutas del sistema de archivos orientadas a objetos (PEP 428).

- `selectors`: Multiplexación de E/S eficiente y de alto nivel, construida sobre las primitivas del módulo `select` (parte de PEP 3156).

- `statistics`: Una básica numerically stable statistics library (PEP 450).

- `tracemalloc`: Trace Python memory allocations (PEP 454).

Mejora significativa de los módulos de la biblioteca:

- Funciones genéricas de despacho único en `functools` (PEP 443).

- Nuevo `pickle` protocolo 4 (PEP 3154).

- `multiproceso` tiene ahora una opción para evitar el uso de os.fork en Unix (bpo-8713).

- `email` tiene un nuevo submódulo, `contentmanager`, y una nueva subclase `Message` (`EmailMessage`) que simplifica el manejo de MIME (bpo-18891).

- Los módulos `inspect` y `pydoc` son ahora capaces de introspeccionar correctamente una variedad mucho más amplia de objetos invocables, lo que mejora la salida del sistema Python `help()`.

- La API del módulo `ipaddress` ha sido declarada estable

Mejoras en la seguridad:

- Algoritmo hash seguro e intercambiable (PEP 456).

- Hacer no heredables los descriptores de archivo recién creados (PEP 446) para evitar la filtración de descriptores de archivo a los procesos hijos.

- Nueva opción de línea de comandos para modo aislado, (bpo-16499).

- `multiprocessing` tiene ahora una opción para evitar el uso de os.fork en Unix. spawn y forkserver son más seguros porque evitan compartir datos con los procesos hijos.

- Los procesos hijos de `multiprocessing` en Windows ya no heredan todos los manejadores heredables del padre, sólo los necesarios.

- Una nueva función `hashlib.pbkdf2_hmac()` proporciona la función de derivación de clave basada en contraseña PKCS#5 2.

- Soporte de TLSv1.1 y TLSv1.2 para `ssl`.

- Recuperación de certificados del soporte del almacén de certificados del sistema Windows para `ssl`.

- Soporte SNI (Server Name Indication) del lado del servidor para `ssl`.

- La clase `ssl.SSLContext` tiene un mucho que mejorar.

- Todos los módulos de la biblioteca estándar que soportan SSL admiten ahora la verificación de certificados de servidor, incluida la coincidencia de nombres de host (`ssl.match_hostname()`) y las CRL (listas de revocación de certificados, véase `ssl.SSLContext.load_verify_locations()`).

Mejoras en la implementación de CPython:

- Finalización segura de objetos (PEP 442).

- Aprovechando PEP 442, en la mayoría de los casos los globales de los módulos ya no se establecen como Ninguno durante la finalización (bpo-18214).

- Asignadores de memoria configurable (PEP 445).

- Consultorio de argumentos (PEP 436).

Por favor, siga leyendo para ver una lista completa de los cambios orientados al usuario, incluyendo muchas otras mejoras menores, optimizaciones de CPython, elementos obsoletos y posibles problemas de portabilidad.

## Nuevas Funciones

### PEP 453: Arranque explícito de PIP en instalaciones de Python

#### Puesta en marcha de pip por defecto

El nuevo módulo `ensurepip` (definido en PEP 453) proporciona un mecanismo estándar multiplataforma para arrancar el instalador pip en instalaciones de Python y entornos virtuales. La versión de `pip` incluida con Python 3.4.0 es `pip` 1.5.4, y las futuras versiones de mantenimiento de 3.4.x actualizarán la versión incluida a la última versión de `pip` que esté disponible en el momento de crear la versión candidata.

Por defecto, los comandos `pipX` y `pipX.Y` se instalarán en todas las plataformas (donde X.Y representa la versión de la instalación de Python), junto con el paquete de Python `pip` y sus dependencias. En Windows y en los entornos virtuales de todas las plataformas, también se instalará el comando `pip` sin versionar. En otras plataformas, el comando `pip` no versionado en todo el sistema suele referirse a la versión de Python 2 instalada por separado.

La utilidad de línea de comandos `pyvenv` y el módulo `venv` hacen uso del módulo `ensurepip` para que `pip` esté disponible en entornos virtuales. Cuando se utiliza la utilidad de línea de comandos, `pip` se instala por defecto, mientras que cuando se utiliza el módulo `venv` API se debe solicitar explícitamente la instalación de `pip`.

Para las construcciones de CPython source en sistemas POSIX, los comandos `make install` y `make altinstall` arrancan `pip` por defecto. Este comportamiento puede ser controlado a través de las opciones de configuración, y anulado a través de las opciones del Makefile.

En Windows y Mac OS X, los instaladores de CPython ahora instalan por defecto `pip` junto con el propio CPython (los usuarios pueden optar por no instalarlo durante el proceso de instalación). Los usuarios de Windows tendrán que optar por las modificaciones automáticas del `PATH` para que `pip` esté disponible por defecto desde la línea de comandos, de lo contrario se puede acceder a través del lanzador de Python para Windows como `py -m pip`.

Como se discute en el PEP (discussed in the PEP), los empaquetadores de plataformas pueden optar por no instalar estos comandos por defecto, siempre y cuando, cuando se invoquen, proporcionen instrucciones claras y sencillas sobre cómo instalarlos en esa plataforma (normalmente utilizando el gestor de paquetes del sistema).

Nota

Para evitar conflictos entre instalaciones paralelas de Python 2 y Python 3, sólo los comandos versionados `pip3` y `pip3.4` son arrancados por defecto cuando se invoca `ensurepip` directamente - la opción `--default-pip` es necesaria para solicitar también el comando no versionado `pip`. `pyvenv` y el instalador de Windows aseguran que el comando `pip` sin calificar esté disponible en esos entornos, y `pip` siempre puede ser invocado a través del interruptor `-m` en lugar de directamente para evitar la ambigüedad en sistemas con múltiples instalaciones de Python.

#### Cambios en la documentación

Como parte de este cambio, las secciones Instalando módulos de Python y Distribuir módulos de Python de la documentación han sido completamente rediseñadas como breves documentos de inicio y preguntas frecuentes. La mayor parte de la documentación de empaquetado se ha trasladado a la «Guía del usuario de empaquetado de Python» mantenida por la Autoridad de Empaquetado de Python <https://packaging.python.org>`__ y a la documentación de los proyectos individuales.

Sin embargo, como esta migración está aún incompleta, las versiones anteriores de esas guías siguen disponibles como Instalación de Módulos de Python (versión antigua) y Distribución de módulos de Python (versión heredada).

Ver también

PEP 453 – Arranque explícito de pip en instalaciones de Python

  PEP escrito por Donald Stufft y Nick Coghlan, implementado por Donald Stufft, Nick Coghlan, Martin von Löwis y Ned Deily.

### PEP 446: Los descriptores de archivos recién creados no son heredables

PEP 446 hace que los descriptores de archivo recién creados sean no heredables. En general, este es el comportamiento que una aplicación querrá: al lanzar un nuevo proceso, tener archivos actualmente abiertos también en el nuevo proceso puede llevar a todo tipo de errores difíciles de encontrar, y potencialmente a problemas de seguridad.

Sin embargo, hay ocasiones en las que se desea la herencia. Para dar soporte a estos casos, están disponibles las siguientes funciones y métodos nuevos:

- `os.get_inheritable()`, `os.set_inheritable()`

- `os.get_handle_inheritable()`, `os.set_handle_inheritable()`

- `socket.socket.get_inheritable()`, `socket.socket.set_inheritable()`

Ver también

PEP 446 – Hacer que los descriptores de archivo recién creados no sean heredables

  PEP escrito y aplicado por Victor Stinner.

### Mejoras en el manejo de códecs

Desde que se introdujo por primera vez, el módulo `codecs` siempre ha pretendido funcionar como un sistema de codificación y decodificación dinámica de tipo neutro. Sin embargo, su estrecho acoplamiento con el modelo de texto de Python, especialmente los métodos de conveniencia restringidos a los tipos `str`, `bytes` y `bytearray`, ha ocultado históricamente este hecho.

Como paso clave para aclarar la situación, las funciones de conveniencia `codecs.encode()` y `codecs.decode()` están ahora debidamente documentadas en Python 2.7, 3.3 y 3.4. Estas funciones han existido en el módulo `codecs` (y han sido cubiertas por el conjunto de pruebas de regresión) desde Python 2.4, pero anteriormente sólo se podían descubrir a través de la introspección en tiempo de ejecución.

A diferencia de los métodos de conveniencia de `str`, `bytes` y `bytearray`, las funciones de conveniencia de `codecs` soportan codificaciones arbitrarias tanto en Python 2 como en Python 3, en lugar de limitarse a codificaciones de texto Unicode (en Python 3) o a <->conversiones de `basestring` (en Python 2).

En Python 3.4, el intérprete es capaz de identificar las codificaciones no textuales conocidas proporcionadas en la biblioteca estándar y dirigir a los usuarios hacia estas funciones de conveniencia de propósito general cuando sea apropiado:

    >>> b"abcdef".decode("hex")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    LookupError: 'hex' is not a text encoding; use codecs.decode() to handle arbitrary codecs

    >>> "hello".encode("rot13")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    LookupError: 'rot13' is not a text encoding; use codecs.encode() to handle arbitrary codecs

    >>> open("foo.txt", encoding="hex")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    LookupError: 'hex' is not a text encoding; use codecs.open() to handle arbitrary codecs

En un cambio relacionado, siempre que sea factible sin romper la compatibilidad con versiones anteriores, las excepciones planteadas durante las operaciones de codificación y decodificación se envuelven en una excepción encadenada del mismo tipo que menciona el nombre del códec responsable de producir el error:

    >>> import codecs

    >>> codecs.decode(b"abcdefgh", "hex")
    Traceback (most recent call last):
      File "/usr/lib/python3.4/encodings/hex_codec.py", line 20, in hex_decode
        return (binascii.a2b_hex(input), len(input))
    binascii.Error: Non-hexadecimal digit found

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    binascii.Error: decoding with 'hex' codec failed (Error: Non-hexadecimal digit found)

    >>> codecs.encode("hello", "bz2")
    Traceback (most recent call last):
      File "/usr/lib/python3.4/encodings/bz2_codec.py", line 17, in bz2_encode
        return (bz2.compress(input), len(input))
      File "/usr/lib/python3.4/bz2.py", line 498, in compress
        return comp.compress(data) + comp.flush()
    TypeError: 'str' does not support the buffer interface

    The above exception was the direct cause of the following exception:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: encoding with 'bz2' codec failed (TypeError: 'str' does not support the buffer interface)

Por último, como muestran los ejemplos anteriores, estas mejoras han permitido restaurar los alias de conveniencia para los códecs no Unicode que fueron restaurados a su vez en Python 3.2. Esto significa que la codificación de datos binarios a y desde su representación hexadecimal (por ejemplo) puede escribirse ahora como:

    >>> from codecs import encode, decode
    >>> encode(b"hello", "hex")
    b'68656c6c6f'
    >>> decode(b"68656c6c6f", "hex")
    b'hello'

Las transformaciones binarias y de texto proporcionadas en la biblioteca estándar se detallan en Transformaciones Binarias y Transformaciones de texto.

(Contribución de Nick Coghlan en bpo-7475, bpo-17827, bpo-17828 y bpo-19619)

### PEP 451: Un tipo ModuleSpec para el sistema de importación

PEP 451 proporciona una encapsulación de la información sobre un módulo que la maquinaria de importación utilizará para cargarlo (es decir, una especificación del módulo). Esto ayuda a simplificar tanto la implementación de la importación como varias APIs relacionadas con la importación. El cambio es también un peldaño para varias mejoras futuras relacionadas con la importación.

Los cambios públicos del PEP son totalmente compatibles con las versiones anteriores. Además, deberían ser transparentes para todos, excepto para los autores de los importadores. Los métodos del buscador y del cargador de claves han quedado obsoletos, pero seguirán funcionando. Los nuevos importadores deben utilizar los nuevos métodos descritos en el PEP. Los importadores existentes deben ser actualizados para implementar los nuevos métodos. Consulte la sección Obsoleto para obtener una lista de los métodos que deben ser reemplazados y sus sustituciones.

### Otros cambios de lenguaje

Algunos de los cambios mas pequeños hechos al núcleo del lenguaje de Python son:

- Base de datos Unicode actualizada a la versión 6.3 de UCD.

- `min()` y `max()` aceptan ahora un argumento por defecto que puede utilizarse para especificar el valor que devuelven si el iterable que están evaluando no tiene elementos. (Contribuido por Julian Berman en bpo-18111.)

- Los objetos del módulo son ahora `weakref`’able.

- Los atributos del módulo `file__` (y los valores relacionados) deberían ahora contener siempre rutas absolutas por defecto, con la única excepción de `main__.__file__` cuando un script ha sido ejecutado directamente usando una ruta relativa. (Contribuido por Brett Cannon en bpo-18416.)

- Todos los códecs UTF-* (excepto UTF-7) rechazan ahora los sustitutos tanto durante la codificación como la decodificación, a menos que se utilice el controlador de errores `surrogatepass`, con la excepción del decodificador UTF-16 (que acepta pares de sustitutos válidos) y el codificador UTF-16 (que los produce al codificar caracteres no BMP). (Contribución de Victor Stinner, Kang-Hao (Kenny) Lu y Serhiy Storchaka en bpo-12892)

- Nuevo EBCDIC alemán codec `cp273`. (Contribución de Michael Bierenfeld y Andrew Kuchling en bpo-1097797)

- Nuevo Ucraniano codec `cp1125` (Contribuido por Serhiy Storchaka en bpo-19668.)

- `bytes`.join() y `bytearray`.join() aceptan ahora objetos buffer arbitrarios como argumentos. (Contribuido por Antoine Pitrou en bpo-15958.)

- El constructor de `int` ahora acepta cualquier objeto que tenga un método `index__` para su argumento base. (Contribuido por Mark Dickinson en bpo-16772.)

- Los objetos Frame tienen ahora un método `clear()` que borra todas las referencias a las variables locales del frame. (Contribuido por Antoine Pitrou en bpo-17934.)

- `memoryview` está ahora registrada como `Sequence`, y soporta el builtin `reversed()`. (Contribución de Nick Coghlan y Claudiu Popa en bpo-18690 y bpo-19078)

- Las firmas reportadas por `help()` han sido modificadas y mejoradas en varios casos como resultado de la introducción de Argument Clinic y otros cambios en los módulos `inspect` y `pydoc`.

- `__length_hint__()` es ahora parte de la especificación formal del lenguaje (ver PEP 424). (Contribuido por Armin Ronacher en bpo-16148.)

## Nuevos Módulos

### asyncio

El nuevo módulo `asyncio` (definido en PEP 3156) proporciona un modelo de bucle de eventos enchufable estándar para Python, proporcionando un sólido soporte de IO asíncrono en la biblioteca estándar, y facilitando que otras implementaciones de bucle de eventos interoperen con la biblioteca estándar y entre sí.

Para Python 3.4, este módulo se considera un provisional API.

Ver también

PEP 3156 – Soporte de IO asíncrono reiniciado: el módulo «asyncio

  PEP redactado y ejecutado por Guido van Rossum.

### ensurepip

El nuevo módulo `ensurepip` es la infraestructura principal para la implementación de PEP 453. En el curso normal de los acontecimientos, los usuarios finales no necesitarán interactuar con este módulo, pero puede utilizarse para arrancar manualmente `pip` si se rechaza el arranque automático en una instalación o entorno virtual.

`ensurepip` incluye una copia de `pip`, actualizada a partir de la primera versión candidata de la versión de CPython con la que se envía (esto se aplica tanto a las versiones de mantenimiento como a las versiones de características). `ensurepip` no tiene acceso a Internet. Si la instalación tiene acceso a Internet, después de ejecutar `ensurepip` se puede utilizar el paquete `pip` para actualizar `pip` a una versión más reciente que la incluida. (Ten en cuenta que esa versión actualizada de `pip` se considera un paquete instalado por separado y no se eliminará si se desinstala Python)

El módulo se llama ensure pip porque si se llama cuando `pip` ya está instalado, no hace nada. También tiene una opción `--upgrade` que hará que se instale la copia incluida de `pip` si la versión instalada de `pip` es más antigua que la copia incluida.

### enum

El nuevo módulo `enum` (definido en PEP 435) proporciona una implementación estándar de los tipos de enumeración, lo que permite a otros módulos (como `socket`) proporcionar mensajes de error más informativos y un mejor soporte de depuración al sustituir las constantes enteras opacas por valores de enumeración compatibles con versiones anteriores.

Ver también

PEP 435 – Añadir un tipo Enum a la biblioteca estándar de Python

  PEP escrito por Barry Warsaw, Eli Bendersky y Ethan Furman, implementado por Ethan Furman.

### pathlib

El nuevo módulo `pathlib` ofrece clases que representan las rutas del sistema de ficheros con una semántica apropiada para diferentes sistemas operativos. Las clases de rutas se dividen entre rutas puras, que proporcionan operaciones puramente computacionales sin E/S, y rutas concretas, que heredan de las rutas puras pero también proporcionan operaciones de E/S.

Para Python 3.4, este módulo se considera un provisional API.

Ver también

PEP 428 – El módulo pathlib – rutas del sistema de archivos orientadas a objetos

  PEP escrito y aplicado por Antoine Pitrou.

### selectores

El nuevo módulo `selectors` (creado como parte de la implementación de PEP 3156) permite una multiplexación de E/S eficiente y de alto nivel, construida sobre las primitivas del módulo `select`.

### estadísticas

El nuevo módulo `statistics` (definido en PEP 450) ofrece algunas funciones estadísticas básicas directamente en la biblioteca estándar. Este módulo permite calcular la media, la mediana, la moda, la varianza y la desviación estándar de una serie de datos.

Ver también

PEP 450 – Añadir un módulo de estadísticas a la biblioteca estándar

  PEP escrito y aplicado por Steven D’Aprano

### tracemalloc

El nuevo módulo `tracemalloc` (definido en PEP 454) es una herramienta de depuración para rastrear los bloques de memoria asignados por Python. Proporciona la siguiente información:

- Rastrear dónde se asignó un objeto

- Estadísticas sobre los bloques de memoria asignados por nombre de archivo y por número de línea: tamaño total, número y tamaño medio de los bloques de memoria asignados

- Calcular las diferencias entre dos instantáneas para detectar fugas de memoria

Ver también

PEP 454 – Añade un nuevo módulo tracemalloc para rastrear las asignaciones de memoria de Python

  PEP escrito y aplicado por Victor Stinner

## Módulos mejorados

### abc

La nueva función `abc.get_cache_token()` puede utilizarse para saber cuándo invalidar las cachés que se ven afectadas por cambios en el gráfico de objetos. (Contribuido por Łukasz Langa en bpo-16832.)

La nueva clase `ABC` tiene `ABCMeta` como metaclase. Usar `ABC` como clase base tiene esencialmente el mismo efecto que especificar `metaclass=abc.ABCMeta`, pero es más sencillo de escribir y más fácil de leer. (Contribuido por Bruno Dupuis en bpo-16049.)

### aifc

El método `getparams()` devuelve ahora una tupla con nombre en lugar de una tupla simple. (Contribuido por Claudiu Popa en bpo-17818.)

`aifc.open()` ahora soporta el protocolo de gestión de contexto: cuando se utiliza en un bloque `with`, el método `close()` del objeto devuelto será llamado automáticamente al final del bloque. (Contribuido por Serhiy Storchacha en bpo-16486.)

Los métodos `writeframesraw()` y `writeframes()` aceptan ahora cualquier bytes-like object. (Contribuido por Serhiy Storchaka en bpo-8311.)

### argparse

La clase `FileType` acepta ahora los argumentos encoding y errors, que se pasan a `open()`. (Contribuido por Lucas Maystre en bpo-11175.)

### audioop

`audioop` ahora soporta muestras de 24 bits. (Contribuido por Serhiy Storchaka en bpo-12866.)

La nueva función `byteswap()` convierte muestras big-endian en little-endian y viceversa. (Contribuido por Serhiy Storchaka en bpo-19641.)

Todas las funciones `audioop` aceptan ahora cualquier bytes-like object. No se aceptan cadenas: antes no funcionaban, ahora dan un error de inmediato. (Contribuido por Serhiy Storchaka en bpo-16685.)

### base64

Las funciones de codificación y decodificación de `base64` aceptan ahora cualquier bytes-like object en los casos en que antes se requería una instancia de `bytes` o `bytearray`. (Contribución de Nick Coghlan en bpo-17839.)

Las nuevas funciones `a85encode()`, `a85decode()`, `b85encode()`, y `b85decode()` proporcionan la capacidad de codificar y decodificar datos binarios desde y hacia los formatos `Ascii85` y git/mercurial `Base85`, respectivamente. Las funciones `a85` tienen opciones que se pueden utilizar para hacerlas compatibles con las variantes de la codificación `Ascii85`, incluyendo la variante de Adobe. (Contribuido por Martin Morrison, el proyecto Mercurial, Serhiy Storchaka y Antoine Pitrou en bpo-17618)

### colecciones

El método `ChainMap.new_child()` acepta ahora un argumento m que especifica el mapa hijo a añadir a la cadena. Esto permite utilizar un mapa existente y/o un tipo de mapa personalizado para el hijo. (Contribuido por Vinay Sajip en bpo-16613.)

### colorsys

El número de dígitos en los coeficientes para las conversiones RGB — YIQ se ha ampliado para que coincidan con las versiones FCC NTSC. El cambio en los resultados debería ser inferior al 1% a y puede coincidir mejor con los resultados encontrados en otros lugares. (Contribución de Brian Landers y Serhiy Storchaka en bpo-14323.)

### contextlib

El nuevo gestor de contexto `contextlib.suppress` ayuda a clarificar la intención del código que suprime deliberadamente las excepciones de una única sentencia. (Contribuido por Raymond Hettinger en bpo-15806 y Zero Piraeus en bpo-19266)

El nuevo gestor de contexto `contextlib.redirect_stdout()` facilita a los scripts de utilidades el manejo de APIs inflexibles que escriben su salida en `sys.stdout` y no proporcionan ninguna opción para redirigirla. Usando el gestor de contexto, la salida de `sys.stdout` puede ser redirigida a cualquier otro flujo o, junto con `io.StringIO`, a una cadena. Esto último puede ser especialmente útil, por ejemplo, para capturar la salida de una función escrita para implementar una interfaz de línea de comandos. Se recomienda sólo para scripts de utilidad porque afecta al estado global de `sys.stdout`. (Contribuido por Raymond Hettinger en bpo-15805.)

También se ha actualizado la documentación de `contextlib` para incluir una discusión de las diferencias entre gestores de contexto de un solo uso, reutilizables y reentrantes.

### dbm

Los objetos `dbm.open()` soportan ahora el protocolo de gestión de contexto. Cuando se utiliza en una sentencia `with`, el método `close` del objeto de base de datos será llamado automáticamente al final del bloque. (Contribución de Claudiu Popa y Nick Coghlan en bpo-19282)

### dis

Las funciones `show_code()`, `dis()`, `distb()`, y `disassemble()` aceptan ahora un argumento de archivo que controla dónde escriben su salida.

El módulo `dis` se construye ahora en torno a una clase `Instruction` que proporciona acceso orientado a objetos a los detalles de cada operación individual del código de bytes.

Un nuevo método, `get_instructions()`, proporciona un iterador que emite el flujo de instrucciones para un trozo de código Python dado. Por lo tanto, ahora es posible escribir un programa que inspeccione y manipule un objeto de código de bytes de forma diferente a la proporcionada por el propio módulo `dis`. Por ejemplo:

    >>> import dis
    >>> for instr in dis.get_instructions(lambda x: x + 1):
    ...     print(instr.opname)
    LOAD_FAST
    LOAD_CONST
    BINARY_ADD
    RETURN_VALUE

Las distintas herramientas de visualización del módulo `dis` se han reescrito para utilizar estos nuevos componentes.

Además, una nueva clase de fácil aplicación `Bytecode` proporciona una API orientada a objetos para inspeccionar el código de bytes tanto en forma legible para el ser humano como para iterar sobre las instrucciones. El constructor `Bytecode` toma los mismos argumentos que `get_instruction()` (más un desplazamiento actual opcional), y el objeto resultante puede ser iterado para producir objetos `Instruction`. Pero también tiene un método `dis`, equivalente a llamar a `dis` en el argumento del constructor, pero devuelto como una cadena de varias líneas:

    >>> bytecode = dis.Bytecode(lambda x: x + 1, current_offset=3)
    >>> for instr in bytecode:
    ...     print('{} ({})'.format(instr.opname, instr.opcode))
    LOAD_FAST (124)
    LOAD_CONST (100)
    BINARY_ADD (23)
    RETURN_VALUE (83)
    >>> bytecode.dis().splitlines()
    ['  1           0 LOAD_FAST                0 (x)',
     '      -->     3 LOAD_CONST               1 (1)',
     '              6 BINARY_ADD',
     '              7 RETURN_VALUE']

`Bytecode` también tiene un método de clase, `from_traceback()`, que proporciona la capacidad de manipular un traceback (es decir, `print(Bytecode.from_traceback(tb).dis())` es equivalente a `distb(tb)`).

(Contribución de Nick Coghlan, Ryan Kelly y Thomas Kluyver en bpo-11816 y Claudiu Popa en bpo-17916)

La nueva función `stack_effect()` calcula el efecto en la pila de Python de un opcode y un argumento dados, información que no está disponible de otro modo. (Contribuido por Larry Hastings en bpo-19722.)

### doctest

Una nueva flag de opción, `FAIL_FAST`, detiene la ejecución de la prueba tan pronto como se detecta el primer fallo. (Contribuido por R. David Murray y Daniel Urban en bpo-16522.)

La interfaz de línea de comandos de `doctest` utiliza ahora `argparse`, y tiene dos nuevas opciones, `-` y `-f`. `-o` permite <doctest-options> especificar las opciones de opciones doctest en la línea de órdenes, y `-f` es una abreviatura de `- FAIL_FAST` (en paralelo a la opción similar soportada por el CLI de `unittest`). (Contribuido por R. David Murray en bpo-11390.)

`doctest` ahora encontrará doctests en las cadenas del módulo de extensión `doc__`. (Contribuido por Zachary Ware en bpo-3158.)

### email

`as_string()` acepta ahora un argumento policy para anular la política por defecto del mensaje al generar una representación de cadena del mismo. Esto significa que `as_string` puede utilizarse en más circunstancias, en lugar de tener que crear y utilizar un `generator` para pasar parámetros de formato a su método `flatten`. (Contribuido por R. David Murray en bpo-18600.)

Nuevo método `as_bytes()` añadido para producir una representación en bytes del mensaje de forma similar a como `as_string` produce una representación en cadena. No acepta el argumento maxheaderlen, pero sí los argumentos unixfrom y policy. El método `Message` `__bytes__()` lo llama, lo que significa que `bytes(mymsg)` producirá ahora el resultado intuitivo: un objeto bytes que contiene el mensaje completamente formateado. (Contribuido por R. David Murray en bpo-18600.)

El mensaje `Message.set_param()` acepta ahora un argumento de palabra clave replace. Cuando se especifica, la cabecera asociada se actualizará sin cambiar su ubicación en la lista de cabeceras. Por compatibilidad, el valor por defecto es `False`. (Contribuido por R. David Murray en bpo-18891.)

Se han añadido un par de nuevas subclases de `Message` (`EmailMessage` y `MIMEPart`), junto con un nuevo submódulo, `contentmanager` y un nuevo atributo `policy` `content_manager`. Toda la documentación se encuentra actualmente en el nuevo módulo, que se añade como parte del nuevo provisional API de email. Estas clases proporcionan una serie de nuevos métodos que facilitan la extracción e inserción de contenidos en los mensajes de correo electrónico. Para más detalles, consulte la documentación de `contentmanager` y la email: Ejemplos. Estas adiciones a la API completan la mayor parte del trabajo que estaba previsto como parte del proyecto email6. Está previsto que la API, actualmente provisional, se convierta en la definitiva en Python 3.5 (posiblemente con algunos añadidos menores en el área de gestión de errores). (Contribuido por R. David Murray en bpo-18891.)

### archivoecmp

Una nueva función `clear_cache()` ofrece la posibilidad de borrar la caché de comparación `filecmp`, que utiliza la información de `os.stat()` para determinar si el fichero ha cambiado desde la última comparación. Esto puede usarse, por ejemplo, si el archivo puede haber sido modificado y vuelto a comprobar en menos tiempo que la resolución del campo de tiempo de modificación de un archivo del sistema de archivos en particular. (Contribuido por Mark Levitt en bpo-18149.)

El nuevo atributo del módulo `DEFAULT_IGNORES` proporciona la lista de directorios que se utilizan como valor por defecto para el parámetro ignore de la función `dircmp()`. (Contribuido por Eli Bendersky en bpo-15442.)

### functools

El nuevo descriptor `partialmethod()` aporta la aplicación de argumentos parciales a los descriptores, al igual que `partial()` proporciona para los callables normales. El nuevo descriptor también facilita la obtención de llamadas arbitrarias (incluyendo instancias de `partial()`) para que se comporten como métodos de instancia normales cuando se incluyen en la definición de una clase. (Contribución de Alon Horev y Nick Coghlan en bpo-4331)

El nuevo decorador `singledispatch()` aporta soporte para funciones genéricas single-dispatch a la biblioteca estándar de Python. Mientras que la programación orientada a objetos se centra en agrupar múltiples operaciones sobre un conjunto común de datos en una clase, una función genérica se centra en agrupar múltiples implementaciones de una operación que le permite trabajar con diferentes tipos de datos.

Ver también

PEP 443 – Funciones genéricas de despacho único

  PEP escrito e implementado por Łukasz Langa.

`total_ordering()` ahora soporta un valor de retorno de `NotImplemented` de la función de comparación subyacente. (Contribuido por Katie Miller en bpo-10042.)

Una versión en python puro de la función `partial()` está ahora en la stdlib; en CPython está anulada por la versión acelerada en C, pero está disponible para que otras implementaciones la usen. (Contribuido por Brian Thorne en bpo-12428.)

### gc

La nueva función `get_stats()` devuelve una lista de tres diccionarios por generación que contienen las estadísticas de las colecciones desde el inicio del intérprete. (Contribuido por Antoine Pitrou en bpo-16351.)

### glob

Una nueva función `escape()` proporciona una forma de escapar los caracteres especiales de un nombre de archivo para que no formen parte de la expansión globbing sino que se comparen literalmente. (Contribuido por Serhiy Storchaka en bpo-8402.)

### hashlib

Una nueva función `hashlib.pbkdf2_hmac()` proporciona la función de derivación de clave basada en contraseña PKCS#5 2. (Contribuido por Christian Heimes en bpo-18582.)

El atributo `name` de los objetos hash `hashlib` es ahora una interfaz formalmente soportada. Siempre ha existido en el `hashlib` de CPython (aunque no devolvía nombres en minúsculas para todos los hashes soportados), pero no era una interfaz pública y por eso algunas otras implementaciones de Python no la han soportado previamente. (Contribuido por Jason R. Coombs en bpo-18532.)

### hmac

`hmac` acepta ahora `bytearray` así como `bytes` para el argumento clave de la función `new()`, y el parámetro msg tanto de la función `new()` como del método `update()` acepta ahora cualquier tipo soportado por el módulo `hashlib`. (Contribuido por Jonas Borgström en bpo-18240.)

El argumento digestmod de la función `hmac.new()` puede ser ahora cualquier nombre de digesto hash reconocido por `hashlib`. Además, el comportamiento actual en el que el valor de digestmod por defecto es `MD5` queda obsoleto: en una futura versión de Python no habrá valor por defecto. (Contribuido por Christian Heimes en bpo-17276.)

Con la adición de los atributos `block_size` y `name` (y la documentación formal del atributo `digest_size`), el módulo `hmac` se ajusta ahora plenamente a la API PEP 247. (Contribuido por Christian Heimes en bpo-18775.)

### html

La nueva función `unescape()` convierte las referencias de caracteres de HTML5 en los correspondientes caracteres Unicode. (Contribuido por Ezio Melotti en bpo-2927.)

`HTMLParser` acepta un nuevo argumento de palabra clave convert_charrefs que, cuando es `True`, convierte automáticamente todas las referencias de caracteres. Por compatibilidad, su valor por defecto es `False`, pero cambiará a `True` en una futura versión de Python, así que te invitamos a establecerlo explícitamente y actualizar tu código para usar esta nueva característica. (Contribuido por Ezio Melotti en bpo-13633.)

El argumento strict de `HTMLParser` está ahora obsoleto. (Contribuido por Ezio Melotti en bpo-15114.)

### http

`send_error()` acepta ahora un parámetro adicional opcional explain que puede usarse para proporcionar una descripción de error extendida, anulando el valor predeterminado si lo hay. Esta descripción de error extendida se formateará utilizando el atributo `error_message_format` y se enviará como cuerpo de la respuesta de error. (Contribuido por Karl Cow en bpo-12921.)

El `http.server` interfaz de línea de comandos tiene ahora una opción `-b/--bind` que hace que el servidor escuche en una dirección específica. (Contribuido por Malte Swart en bpo-17764.)

### idlelib y IDLE

Como idlelib implementa el shell y el editor de IDLE y no está pensado para ser importado por otros programas, recibe mejoras con cada versión. Vea `Lib/idlelib/NEWS.txt` para una lista acumulativa de cambios desde la versión 3.3.0, así como los cambios realizados en futuras versiones 3.4.x. Este fichero también está disponible en el diálogo de IDLE Ayuda ‣ Sobre IDLE.

### importlib

El ABC de `InspectLoader` define un nuevo método, `source_to_code()` que acepta datos de origen y una ruta y devuelve un objeto de código. La implementación por defecto es equivalente a `compile(data, path, 'exec', dont_inherit=True)`. (Contribuido por Eric Snow y Brett Cannon en bpo-15627.)

`InspectLoader` también tiene ahora una implementación por defecto para el método `get_code()`. Sin embargo, normalmente será deseable anular la implementación por defecto por razones de rendimiento. (Contribuido por Brett Cannon en bpo-18072.)

La función `reload()` ha sido trasladada de `imp` a `importlib` como parte de la eliminación del módulo `imp`. (Contribuido por Berker Peksag en bpo-18193.)

`importlib.util` tiene ahora un atributo `MAGIC_NUMBER` que proporciona acceso al número de versión del código de bytes. Esto sustituye a la función `get_magic()` del módulo `imp`, ya obsoleto. (Contribuido por Brett Cannon en bpo-18192.)

Las nuevas funciones `importlib.util` `cache_from_source()` y `source_from_cache()` sustituyen a las funciones con el mismo nombre del módulo `imp`, ya obsoleto. (Contribuido por Brett Cannon en bpo-18194.)

El bootstrap `importlib` `NamespaceLoader` se ajusta ahora al ABC de `InspectLoader`, lo que significa que `runpy` y `python -m` pueden utilizarse ahora con paquetes de espacios de nombres. (Contribuido por Brett Cannon en bpo-18058.)

`importlib.util` tiene una nueva función `decode_source()` que decodifica la fuente a partir de bytes utilizando el procesamiento universal de nuevas líneas. Esto es útil para implementar los métodos `InspectLoader.get_source()`.

`importlib.machinery.ExtensionFileLoader` tiene ahora un método `get_filename()`. Esto fue omitido inadvertidamente en la implementación original. (Contribuido por Eric Snow en bpo-19152.)

### inspeccionar

El módulo `inspect` ofrece ahora una interfaz de línea de comandos básica para mostrar rápidamente el código fuente y otra información de módulos, clases y funciones. (Contribución de Claudiu Popa y Nick Coghlan en bpo-18626)

`unwrap()` facilita el desenvolvimiento de las cadenas de funciones envolventes creadas por `functools.wraps()` (y cualquier otra API que establezca el atributo `__wrapped__` en una función envolvente). (Contribución de Daniel Urban, Aaron Iles y Nick Coghlan en bpo-13266)

Como parte de la implementación del nuevo módulo `enum`, el módulo `inspect` tiene ahora un soporte sustancialmente mejor para los métodos personalizados `__dir__` y los atributos de clase dinámicos proporcionados a través de metaclases. (Contribuido por Ethan Furman en bpo-18929 y bpo-19030)

`getfullargspec()` y `getargspec()` utilizan ahora la API `signature()`. Esto les permite soportar un rango mucho más amplio de llamadas, incluyendo aquellas con atributos `__signature__`, aquellas con metadatos proporcionados por la clínica de argumentos, objetos `functools.partial()` y más. Tenga en cuenta que, a diferencia de `signature()`, estas funciones siguen ignorando los atributos `__wrapped__`, e informan del primer argumento ya ligado para los métodos ligados, por lo que sigue siendo necesario actualizar su código para utilizar `signature()` directamente si se desean esas características. (Contribuido por Yury Selivanov en bpo-17481.)

`signature()` ahora soporta los tipos de pato de las funciones CPython, lo que añade soporte para las funciones compiladas con Cython. (Contribuido por Stefan Behnel y Yury Selivanov en bpo-17159)

### dirección IP

`ipaddress` se añadió a la biblioteca estándar en Python 3.3 como una provisional API. Con el lanzamiento de Python 3.4, se ha eliminado esta calificación: `ipaddress` se considera ahora una API estable, cubierta por los requisitos normales de la biblioteca estándar para mantener la compatibilidad hacia atrás.

Una nueva propiedad `is_global` es `True` si una dirección es enrutable globalmente. (Contribuido por Peter Moody en bpo-17400.)

### Tres mejoras más pequeñas en el módulo `logging`, todas implementadas por Vinay Sajip, son:

La clase `TimedRotatingFileHandler` tiene un nuevo parámetro atTime que puede utilizarse para especificar la hora del día en que debe producirse la renovación. (Contribuido por Ronald Oussoren en bpo-9556.)

`SocketHandler` y `DatagramHandler` ahora soportan sockets de dominio Unix (estableciendo puerto a `None`). (Contribuido por Vinay Sajip en el commit ce46195b56a9.)

`fileConfig()` ahora acepta una instancia de la subclase `configparser.RawConfigParser` para el parámetro fname. Esto facilita el uso de un archivo de configuración cuando la configuración de registro es sólo una parte de la configuración general de la aplicación, o cuando la aplicación modifica la configuración antes de pasarla a `fileConfig()`. (Contribuido por Vinay Sajip en bpo-16110.)

Los datos de configuración de registro recibidos desde un socket a través de la función `logging.config.listen()` pueden ahora ser validados antes de ser procesados suministrando una función de verificación como argumento de la nueva palabra clave verify. (Contribuido por Vinay Sajip en bpo-15452.)

### mariscal

La versión por defecto de `marshal` ha sido aumentada a 3. El código que implementa la nueva versión restablece el comportamiento de Python2 de registrar sólo una copia de las cadenas internadas y preservar la internación en la deserialización, y extiende esta capacidad de «una copia» a cualquier tipo de objeto (incluyendo el manejo de referencias recursivas). Esto reduce tanto el tamaño de los archivos `.pyc` como la cantidad de memoria que ocupa un módulo en la memoria cuando se carga desde un archivo `.pyc` (o `.pyo`). (Contribuido por Kristján Valur Jónsson en bpo-16475, con mejoras adicionales de velocidad por Antoine Pitrou en bpo-19219)

### mmap

los objetos mmap ahora pueden ser `weakref` ed. (Contribución de Valerie Lambert en bpo-4885.)

### multiprocesamiento

En Unix se han añadido métodos de comienzo `spawn` y `forkserver`, para iniciar procesos usando `multiprocessing`. Estos hacen que la mezcla de procesos con hilos sea más robusta, y el método `spawn` coincide con la semántica que el multiprocesamiento siempre ha utilizado en Windows. La nueva función `get_all_start_methods()` informa de todos los métodos de inicio disponibles en la plataforma, `get_start_method()` informa del método de inicio actual, y `set_start_method()` establece el método de inicio. (Contribuido por Richard Oudkerk en bpo-8713.)

`multiprocessing` también tiene ahora el concepto de `contexto`, que determina cómo se crean los procesos hijos. La nueva función `get_context()` devuelve un contexto que utiliza un método de inicio especificado. Tiene la misma API que el propio módulo `multiprocessing`, por lo que se puede utilizar para crear `pool` y otros objetos que operarán dentro de ese contexto. Esto permite que un framework y una aplicación o diferentes partes de la misma aplicación utilicen el multiprocesamiento sin interferir entre sí. (Contribuido por Richard Oudkerk en bpo-18999.)

Excepto cuando se utiliza el antiguo método de inicio fork, los procesos hijos ya no heredan los handles/descriptores de archivo innecesarios de sus padres (parte de bpo-8713).

`multiprocessing` ahora se basa en `runpy` (que implementa el conmutador `-m`) para inicializar `__main__` apropiadamente en los procesos hijos cuando se utilizan los métodos de inicio `spawn` o `forkserver`. Esto resuelve algunos casos extremos en los que la combinación de multiprocesamiento, el conmutador de línea de comandos `-m` y las importaciones relativas explícitas podían causar fallos oscuros en los procesos hijos. (Contribuido por Nick Coghlan en bpo-19946.)

### PEP 465, un nuevo operador de multiplicación de matrices: `a @ b`.

La nueva función `length_hint()` proporciona una implementación de la especificación de cómo debe utilizarse el método especial `__length_hint__()`, como parte de la especificación formal PEP 424 de esta característica del lenguaje. (Contribuido por Armin Ronacher en bpo-16148.)

Ahora hay una versión puramente python del módulo `operator` disponible como referencia y para ser utilizada por implementaciones alternativas de Python. (Contribuido por Zachary Ware en bpo-16694.)

### os

Hay nuevas funciones para obtener y establecer la bandera heritable de un descriptor de archivo (`os.get_inheritable()`, `os.set_inheritable()`) o de un handle de Windows (`os.get_handle_inheritable()`, `os.set_handle_inheritable()`).

La nueva función `cpu_count()` informa del número de CPUs disponibles en la plataforma en la que se está ejecutando Python (o `None` si no se puede determinar el recuento). La función `multiprocessing.cpu_count()` está ahora implementada en términos de esta función). (Contribución de Trent Nelson, Yogesh Chaudhari, Victor Stinner y Charles-François Natali en bpo-17914)

`os.path.samestat()` está ahora disponible en la plataforma Windows (y la implementación de `os.path.samefile()` es ahora compartida entre Unix y Windows). (Contribuido por Brian Curtin en bpo-11939.)

`os.path.ismount()` ahora reconoce los volúmenes montados por debajo de la raíz de una unidad en Windows. (Contribuido por Tim Golden en bpo-9035.)

`os.open()` soporta dos nuevas banderas en las plataformas que las proporcionan, `O_PATH` (descriptor de archivo no abierto), y `O_TMPFILE` (archivo temporal sin nombre; a partir de la versión 3.4.0 disponible sólo en sistemas Linux con una versión del kernel de 3.11 o más reciente que tenga cabeceras uapi). (Contribuido por Christian Heimes en bpo-18673 y Benjamin Peterson, respectivamente)

### pdb

`pdb` ha sido mejorado para manejar generadores, `yield`, y `yield from` de una manera más útil. Esto es especialmente útil cuando se depuran programas basados en `asyncio`. (Contribución de Andrew Svetlov y Xavier de Gaye en bpo-16596)

El comando `print` ha sido eliminado de `pdb`, restaurando el acceso a la función de Python `print()` desde la línea de comandos de la pdb. El comando `pdb` de Python2 no tenía un comando `print`; en su lugar, al introducir `print` se ejecutaba la sentencia `print`. En Python3 `print` se convirtió por error en un alias del comando pdb `p`. Sin embargo, `p` imprime la `repr` de su argumento, no la `str` como hacía el comando `print` de Python2. Peor aún, el comando `pdb print` de Python3 ensombrece la función `print` de Python3, haciéndola inaccesible en el prompt de `pdb`. (Contribuido por Connor Osborn en bpo-18764.)

### pepinillo

`pickle` ahora soporta (pero no utiliza por defecto) un nuevo protocolo pickle, el protocolo 4. Este nuevo protocolo aborda una serie de problemas que estaban presentes en los protocolos anteriores, como la serialización de clases anidadas, cadenas y contenedores muy grandes, y clases cuyo método `__new__()` toma argumentos de sólo palabras clave. También proporciona algunas mejoras de eficiencia.

Ver también

PEP 3154 – Protocolo Pickle 4

  PEP escrito por Antoine Pitrou e implementado por Alexandre Vassalotti.

### plistlib

`plistlib` tiene ahora una API que es similar al patrón estándar de los protocolos de serialización de stdlib, con nuevas funciones `load()`, `dump()`, `loads()`, y `dumps()`. (Además del formato XML de plist que ya se soportaba (`FMT_XML`), ahora también se soporta el formato binario de plist (`FMT_BINARY`). (Contribuido por Ronald Oussoren y otros en bpo-14455.)

### poplib

Se han añadido dos nuevos métodos a `poplib`: `capa()`, que devuelve la lista de capacidades anunciadas por el servidor POP, y `stls()`, que cambia una sesión POP3 de texto claro a una sesión POP3 cifrada si el servidor POP lo soporta. (Contribuido por Lorenzo Catucci en bpo-4473.)

### pprint

La clase `PrettyPrinter` del módulo `pprint` y sus funciones `pformat()`, y `pprint()` tienen una nueva opción, compact, que controla cómo se formatea la salida. Actualmente, establecer compact a `True` significa que las secuencias se imprimirán con tantos elementos de secuencia como quepan en el ancho de cada línea (indentada). (Contribuido por Serhiy Storchaka en bpo-19132.)

Las cadenas largas ahora se envuelven usando la sintaxis normal de continuación de línea de Python. (Contribuido por Antoine Pitrou en bpo-17150.)

### pty

`pty.spawn()` ahora devuelve el valor de estado de `os.waitpid()` en el proceso hijo, en lugar de `None`. (Contribución de Gregory P. Smith)

### pydoc

El módulo `pydoc` se basa ahora directamente en la API de introspección `inspect.signature()`, lo que le permite proporcionar información de firma para una mayor variedad de objetos invocables. Este cambio también significa que los atributos `__wrapped__` se tienen ahora en cuenta al mostrar la información de ayuda. (Contribución de Larry Hastings en bpo-19674.)

El módulo `pydoc` ya no muestra el parámetro `self` para los métodos ya vinculados. En su lugar, pretende mostrar siempre la firma actual exacta de la llamada suministrada. (Contribuido por Larry Hastings en bpo-20710.)

Además de los cambios que se han realizado en `pydoc` directamente, su manejo de los métodos personalizados `__dir__` y varios comportamientos del descriptor también se han mejorado sustancialmente por los cambios subyacentes en el módulo `inspect`.

Como el builtin `help()` está basado en `pydoc`, los cambios anteriores también afectan al comportamiento de `help()`.

### re

La nueva función `fullmatch()` y el método `regex.fullmatch()` anclan el patrón en ambos extremos de la cadena a comparar. Esto proporciona una manera de ser explícito sobre el objetivo de la coincidencia, lo que evita una clase de errores sutiles donde los caracteres `$` se pierden durante los cambios de código o la adición de alternativas a una expresión regular existente. (Contribuido por Matthew Barnett en bpo-16203.)

La repr de los regex objects ahora incluye el patrón y las banderas; la repr de los objetos regex ahora incluye el inicio, el final y la parte de la cadena que coincide. (Contribución de Hugo Lopes Tavares y Serhiy Storchaka en bpo-13592 y bpo-17087)

### recurso

La nueva función `prlimit()`, disponible en plataformas Linux con un kernel de versión 2.6.36 o posterior y glibc de 2.13 o posterior, proporciona la capacidad de consultar o establecer los límites de recursos para procesos distintos del que realiza la llamada. (Contribuido por Christian Heimes en bpo-16595.)

En el kernel de Linux versión 2.6.36 o posterior, también hay algunas nuevas constantes específicas de Linux: `RLIMIT_MSGQUEUE`, `RLIMIT_NICE`, `RLIMIT_RTPRIO`, `RLIMIT_RTTIME`, y `RLIMIT_SIGPENDING`. (Contribuido por Christian Heimes en bpo-19324.)

En FreeBSD versión 9 y posteriores, hay algunas nuevas constantes específicas de FreeBSD: `RLIMIT_SBSIZE`, `RLIMIT_SWAP`, y `RLIMIT_NPTS`. (Contribuido por Claudiu Popa en bpo-19343.)

### seleccionar

Los objetos `epoll` ahora soportan el protocolo de gestión de contexto. Cuando se utiliza en una declaración `with`, el método `close()` será llamado automáticamente al final del bloque. (Contribuido por Serhiy Storchaka en bpo-16488.)

Los objetos `devpoll` tienen ahora métodos `fileno()` y `close()`, así como un nuevo atributo `closed`. (Contribuido por Victor Stinner en bpo-18794.)

### estante

Las instancias de `Shelf` ahora pueden utilizarse en declaraciones `with`, y se cerrarán automáticamente al final del bloque `with`. (Contribuido por Filip Gruszczyński en bpo-13896.)

### shutil

`copyfile()` ahora lanza una subclase específica de `Error`, `SameFileError`, cuando el origen y el destino son el mismo fichero, lo que permite a una aplicación tomar la acción apropiada en este error específico. (Contribución de Atsuo Ishimoto y Hynek Schlawack en bpo-1492704)

### smtpd

Las clases `SMTPServer` y `SMTPChannel` aceptan ahora un argumento de palabra clave map que, si se especifica, se pasa a `asynchat.async_chat` como su argumento map. Esto permite que una aplicación no afecte al mapa global de sockets. (Contribuido por Vinay Sajip en bpo-11959.)

### smtplib

`SMTPException` es ahora una subclase de `OSError`, que permite que tanto los errores de nivel de socket como los de nivel de protocolo SMTP sean capturados en una sentencia try/except por un código que sólo se preocupa de si se ha producido o no un error. (Contribuido por Ned Jackson Lovely en bpo-2118.)

### enchufe

El módulo socket ahora soporta el protocolo `CAN_BCM` en las plataformas que lo soportan. (Contribuido por Brian Thorne en bpo-15359.)

Los objetos Socket tienen nuevos métodos para obtener o establecer su bandera heredable, `get_inheritable()` y `set_inheritable()`.

Las constantes `socket.AF_*` y ``socket.SOCK_*` son ahora valores de enumeración utilizando el nuevo módulo `enum`. Esto permite imprimir nombres significativos durante la depuración, en lugar de «números mágicos» enteros.

La constante `AF_LINK` está ahora disponible en BSD y OSX.

`inet_pton()` y `inet_ntop()` son ahora compatibles con Windows. (Contribuido por Atsuo Ishimoto en bpo-7171.)

### sqlite3

Un nuevo parámetro booleano para la función `connect()`, uri, puede usarse para indicar que el parámetro base de datos es una `uri` (véase la documentación SQLite URI). (Contribuido por poq en bpo-13773.)

### ssl

Se han añadido `PROTOCOL_TLSv1_1` y `PROTOCOL_TLSv1_2` (soporte de TLSv1.1 y TLSv1.2); el soporte de estos protocolos sólo está disponible si Python está enlazado con OpenSSL 1.0.1 o posterior. (Contribuido por Michele Orrù y Antoine Pitrou en bpo-16692)

La nueva función `create_default_context()` proporciona una forma estándar de obtener un `SSLContext` cuya configuración pretende ser un equilibrio razonable entre compatibilidad y seguridad. Estos ajustes son más estrictos que los valores por defecto proporcionados por el constructor `SSLContext`, y pueden ser ajustados en el futuro, sin necesidad de una depreciación previa, si los requisitos de seguridad de las mejores prácticas cambian. La nueva práctica recomendada para usar las bibliotecas stdlib que soportan SSL es usar `create_default_context()` para obtener un objeto `SSLContext`, modificarlo si es necesario, y luego pasarlo como el argumento context de la API stdlib apropiada. (Contribuido por Christian Heimes en bpo-19689.)

El método `SSLContext` `load_verify_locations()` acepta un nuevo argumento opcional cadata, que puede utilizarse para proporcionar certificados codificados en PEM o DER directamente mediante cadenas o bytes, respectivamente. (Contribuido por Christian Heimes en bpo-18138.)

La nueva función `get_default_verify_paths()` devuelve una tupla con nombre de las rutas y variables de entorno que el método `set_default_verify_paths()` utiliza para establecer el `cafile` y el `capath` por defecto de OpenSSL. Esto puede ser una ayuda para depurar problemas de verificación por defecto. (Contribuido por Christian Heimes en bpo-18143.)

`SSLContext` tiene un nuevo método, `cert_store_stats()`, que informa del número de certificados `X.509` cargados, certificados `X.509 CA` y listas de revocación de certificados (`crl`), así como un método `get_ca_certs()` que devuelve una lista de los certificados `CA` cargados. (Contribuido por Christian Heimes en bpo-18147.)

Si OpenSSL 0.9.8 o posterior está disponible, `SSLContext` tiene un nuevo atributo `verify_flags` que puede utilizarse para controlar el proceso de verificación del certificado estableciéndolo en alguna combinación de las nuevas constantes `VERIFY_DEFAULT`, `VERIFY_CRL_CHECK_LEAF`, `VERIFY_CRL_CHECK_CHAIN`, o `VERIFY_X509_STRICT`. OpenSSL no realiza ninguna verificación CRL por defecto. (Contribuido por Christien Heimes en bpo-8813.)

Nuevo método `SSLContext` `load_default_certs()` carga un conjunto de certificados de «autoridad de certificación» (CA) por defecto desde ubicaciones predeterminadas, que varían según la plataforma. Puede utilizarse para cargar tanto certificados de autenticación de servidores web TLS (`purpose=``SERVER_AUTH`) para que un cliente los utilice para verificar un servidor, como certificados para que un servidor los utilice para verificar certificados de clientes (`purpose=``CLIENT_AUTH`). (Contribuido por Christian Heimes en bpo-19292.)

Dos nuevas funciones sólo para Windows, `enum_certificates()` y `enum_crls()` ofrecen la posibilidad de recuperar certificados, información de certificados y CRLs del almacén de certificados de Windows. (Contribuido por Christian Heimes en bpo-17134.)

Soporte para SNI (Server Name Indication) del lado del servidor utilizando el nuevo método `ssl.SSLContext.set_servername_callback()`. (Contribuido por Daniel Black en bpo-8109.)

El diccionario devuelto por `SSLSocket.getpeercert()` contiene elementos de extensión `X509v3` adicionales: `crlDistributionPoints`, `calIssuers`, y `OCSP` URIs. (Contribución de Christian Heimes en bpo-18379.)

### stat

El módulo `stat` está ahora respaldado por una implementación en C en `_stat`. Se requiere una implementación en C ya que la mayoría de los valores no están estandarizados y dependen de la plataforma. (Contribuido por Christian Heimes en bpo-11016.)

El módulo soporta las nuevas banderas `ST_MODE`, `S_IFDOOR`, `S_IFPORT`, y `S_IFWHT`. (Contribución de Christian Hiemes en bpo-11016.)

### struct

La nueva función `iter_unpack` y un nuevo método `struct.Struct.iter_unpack()` en formatos compilados proporcionan un desempaquetado en flujo de un buffer que contiene instancias repetidas de un formato de datos dado. (Contribuido por Antoine Pitrou en bpo-17804.)

### subproceso

`check_output()` acepta ahora un argumento input que puede utilizarse para proporcionar el contenido de `stdin` para el comando que se ejecuta. (Contribuido por Zack Weinberg en bpo-16624.)

`getstatus()` y `getstatusoutput()` ahora funcionan en Windows. Este cambio se realizó inadvertidamente en la versión 3.3.4. (Contribuido por Tim Golden en bpo-10197.)

### sunau

El método `getparams()` ahora devuelve una tupla con nombre en lugar de una tupla simple. (Contribuido por Claudiu Popa en bpo-18901.)

`sunau.open()` ahora soporta el protocolo de gestión de contexto: cuando se utiliza en un bloque `with`, el método `close` del objeto devuelto será llamado automáticamente al final del bloque. (Contribuido por Serhiy Storchaka en bpo-18878.)

`AU_write.setsampwidth()` ahora soporta muestras de 24 bits, añadiendo así soporte para escribir 24 muestras usando el módulo. (Contribuido por Serhiy Storchaka en bpo-19261.)

Los métodos `writeframesraw()` y `writeframes()` aceptan ahora cualquier bytes-like object. (Contribuido por Serhiy Storchaka en bpo-8311.)

### sys

La nueva función `sys.getallocatedblocks()` devuelve el número actual de bloques asignados por el intérprete. (En CPython con la configuración por defecto `--with-pymalloc`, se trata de asignaciones realizadas a través de la API `PyObject_Malloc()`) Esto puede ser útil para rastrear las fugas de memoria, especialmente si se automatiza a través de un conjunto de pruebas. (Contribuido por Antoine Pitrou en bpo-13390.)

Cuando el intérprete de Python se inicia en modo interactivo, busca un atributo `__interactivehook__` en el módulo `sys`. Si el atributo existe, se llama a su valor sin argumentos justo antes de iniciar el modo interactivo. La comprobación se realiza después de leer el fichero `PYTHONSTARTUP`, por lo que puede establecerse allí. El módulo `site` lo establece a una función que permite completar el tabulador y guardar el historial (en `~/.python-history`) si la plataforma soporta `readline`. Si no quiere este (nuevo) comportamiento, puede anularlo en `PYTHONSTARTUP`, `sitecustomize`, o `usercustomize` borrando este atributo de `sys` (o poniéndolo en alguna otra llamada). (Contribuido por Éric Araujo y Antoine Pitrou en bpo-5845.)

### tarfile

El módulo `tarfile` soporta ahora una simple Interfaz de línea de comandos cuando se llama como un script directamente o a través de `-m`. Esto puede utilizarse para crear y extraer archivos tarfile. (Contribuido por Berker Peksag en bpo-13477.)

### textwrap

La clase `TextWrapper` tiene dos nuevos atributos/argumentos de construcción: `max_lines`, que limita el número de líneas en la salida, y `placeholder`, que es una cadena que aparecerá al final de la salida si se ha truncado debido a max_lines. Basándose en estas capacidades, una nueva función de conveniencia `shorten()` colapsa todos los espacios en blanco de la entrada a espacios simples y produce una sola línea de un ancho dado que termina con el marcador de posición (por defecto, `[...]`). (Contribuido por Antoine Pitrou y Serhiy Storchaka en bpo-18585 y bpo-18725)

### roscado

El objeto `Thread` que representa el hilo principal puede obtenerse de la nueva función `main_thread()`. En condiciones normales será el hilo desde el que se inició el intérprete de Python. (Contribuido por Andrew Svetlov en bpo-18882.)

### traceback

Una nueva función `traceback.clear_frames()` toma un objeto traceback y borra las variables locales en todos los marcos a los que hace referencia, reduciendo la cantidad de memoria consumida. (Contribuido por Andrew Kuchling en bpo-1565525.)

### tipos

Un nuevo descriptor `DynamicClassAttribute()` proporciona una forma de definir un atributo que actúa normalmente cuando se busca a través de un objeto instancia, pero que se dirige a la clase `__getattr__` cuando se busca a través de la clase. Esto permite tener propiedades activas en una clase, y tener atributos virtuales en la clase con el mismo nombre (ver `Enum` para un ejemplo). (Contribuido por Ethan Furman en bpo-19030.)

### urllib

`urllib.request` ahora soporta URLs `data:` a través de la clase `DataHandler`. (Contribuido por Mathias Panzenböck en bpo-16423.)

El método http que será utilizado por una clase `Request` puede ahora especificarse estableciendo un atributo de clase `method` en la subclase. (Contribuido por Jason R Coombs en bpo-18978.)

Los objetos `Request` son ahora reutilizables: si los atributos `full_url` o `data` se modifican, todas las propiedades internas relevantes se actualizan. Esto significa, por ejemplo, que ahora es posible utilizar el mismo objeto `Request` en más de una llamada `OpenerDirector.open()` con diferentes argumentos data, o modificar la `url` de un `Request`` en lugar de volver a calcularla desde cero. También hay un nuevo método `remove_header()` que puede utilizarse para eliminar las cabeceras de una `Request`. (Contribuido por Alexey Kachayev en bpo-16464, Daniel Wozniak en bpo-17485, y Damien Brecht y Senthil Kumaran en bpo-17272)

Los objetos `HTTPError` tienen ahora un atributo `headers` que proporciona acceso a las cabeceras de respuesta HTTP asociadas al error. (Contribuido por Berker Peksag en bpo-15701.)

### unittest

The `TestCase` class has a new method, `subTest()`, that produces a context manager whose `with` block becomes a «sub-test». This context manager allows a test method to dynamically generate subtests by, say, calling the `subTest` context manager inside a loop. A single test method can thereby produce an indefinite number of separately identified and separately counted tests, all of which will run even if one or more of them fail. For example:

    class NumbersTest(unittest.TestCase):
        def test_even(self):
            for i in range(6):
                with self.subTest(i=i):
                    self.assertEqual(i % 2, 0)

dará como resultado seis subpruebas, cada una identificada en la salida verbose de unittest con una etiqueta que consiste en el nombre de la variable `i` y un valor particular para esa variable (`i=0`, `i=1`, etc). Consulte la versión completa de este ejemplo en Distinguiendo iteraciones de tests empleando subtests. (Contribuido por Antoine Pitrou en bpo-16997.)

`unittest.main()` ahora acepta un iterable de nombres de pruebas para defaultTest, donde antes sólo aceptaba un único nombre de prueba como cadena. (Contribuido por Jyrki Pulliainen en bpo-15132.)

Si `SkipTest` se lanza durante el descubrimiento de la prueba (es decir, en el nivel de módulo en el archivo de prueba), ahora se reporta como un salto en lugar de un error. (Contribuido por Zach Ware en bpo-16935.)

`discover()` ahora ordena los archivos descubiertos para proporcionar un orden de pruebas consistente. (Contribuido por Martin Melin y Jeff Ramnani en bpo-16709.)

`TestSuite` ahora elimina las referencias a las pruebas tan pronto como la prueba se ha ejecutado, si la prueba tiene éxito. En los intérpretes de Python que hacen recolección de basura, esto permite que las pruebas sean recolectadas si no hay nada más que mantenga una referencia a la prueba. Es posible anular este comportamiento creando una subclase `TestSuite` que defina un método personalizado `_removeTestAtIndex`. (Contribución de Tom Wardill, Matt McClure y Andrew Svetlov en bpo-11798)

Un nuevo gestor de contexto de aserción de pruebas, `assertLogs()`, asegurará que un bloque de código dado emita un mensaje de registro utilizando el módulo `logging`. Por defecto, el mensaje puede provenir de cualquier registrador y tener una prioridad de `INFO` o superior, pero se puede especificar tanto el nombre del registrador como un nivel de registro mínimo alternativo. El objeto devuelto por el gestor de contexto puede ser consultado para los mensajes `LogRecord` s y/o formateados que fueron registrados. (Contribuido por Antoine Pitrou en bpo-18937.)

El descubrimiento de pruebas ahora funciona con paquetes de espacios de nombres (Contribuido por Claudiu Popa en bpo-17457.)

Los objetos `unittest.mock` ahora inspeccionan sus firmas de especificación cuando coinciden con las llamadas, lo que significa que un argumento ahora puede coincidir por posición o por nombre, en lugar de sólo por posición. (Contribuido por Antoine Pitrou en bpo-17015.)

Los objetos `mock_open()` tienen ahora métodos `readline` y `readlines`. (Contribuido por Toshio Kuratomi en bpo-17467.)

### venv

`venv` incluye ahora scripts de activación para los shells `csh` y `fish`. (Contribuido por Andrew Svetlov en bpo-15417.)

`EnvBuilder` y la función de conveniencia `create()` toman un nuevo argumento de palabra clave with_pip, que por defecto es `False`, que controla si `EnvBuilder` asegura que `pip` está instalado en el entorno virtual. (Contribuido por Nick Coghlan en bpo-19552 como parte de la implementación de PEP 453)

### onda

El método `getparams()` ahora devuelve una tupla con nombre en lugar de una tupla simple. (Contribuido por Claudiu Popa en bpo-17487.)

`wave.open()` ahora soporta el protocolo de gestión de contexto. (Contribuido por Claudiu Popa en bpo-17616.)

`wave` puede ahora escribir la salida en archivos no buscables. (Contribución de David Jones, Guilherme Polo y Serhiy Storchaka en bpo-5202)

Los métodos `writeframesraw()` y `writeframes()` aceptan ahora cualquier bytes-like object. (Contribuido por Serhiy Storchaka en bpo-8311.)

### weakref

La nueva clase `WeakMethod` simula las referencias débiles a los métodos vinculados. (Contribuido por Antoine Pitrou en bpo-14631.)

La nueva clase `finalize` permite registrar una llamada de retorno para ser invocada cuando un objeto es recogido de la basura, sin necesidad de gestionar cuidadosamente el ciclo de vida de la propia referencia débil. (Contribuido por Richard Oudkerk en bpo-15528.)

La llamada de retorno, si la hay, asociada a un `ref` se expone ahora a través del atributo `__callback__`. (Contribuido por Mark Dickinson en bpo-17643.)

### xml.etree

Un nuevo analizador sintáctico, `XMLPullParser`, permite que una aplicación no bloqueante analice documentos XML. Un ejemplo puede verse en API de consulta para un procesamiento no bloqueante. (Contribuido por Antoine Pitrou en bpo-17741.)

Las funciones `xml.etree.ElementTree` `tostring()` y `tostringlist()`, y el método `ElementTree` `write()`, tienen ahora un parámetro short_empty_elements parámetro de solo keyword que permite controlar si los elementos sin contenido se escriben de forma abreviada (`<tag />`) o expandida (`<tag></tag>`). (Contribución de Ariel Poliak y Serhiy Storchaka en bpo-14377)

### archivo zip

El método `writepy()` de la clase `PyZipFile` tiene una nueva opción filterfunc que puede utilizarse para controlar qué directorios y ficheros se añaden al archivo. Por ejemplo, esto puede ser usado para excluir archivos de prueba del archivo. (Contribuido por Christian Tismer en bpo-19274.)

El parámetro allowZip64 de `ZipFile` y `PyZipfile` es ahora `True` por defecto. (Contribuido por William Mallard en bpo-17201.)

## Cambios en la implementación de CPython

### PEP 445: Personalización de los Asignadores de Memoria de CPython

PEP 445 añade nuevas interfaces de nivel C para personalizar la asignación de memoria en el intérprete de CPython.

Ver también

PEP 445 – Añadir nuevas APIs para personalizar los asignadores de memoria de Python

  PEP escrito y aplicado por Victor Stinner.

### PEP 442: Finalización segura de objetos

PEP 442 elimina las limitaciones y peculiaridades actuales de la finalización de objetos en CPython. Con él, los objetos con métodos `__del__()`, así como los generadores con cláusulas `finally`, pueden ser finalizados cuando forman parte de un ciclo de referencia.

Como parte de este cambio, los globales de los módulos ya no se establecen forzosamente a `None` durante el cierre del intérprete en la mayoría de los casos, sino que se confía en el funcionamiento normal del recolector de basura cíclico. Esto evita toda una clase de errores durante el cierre del intérprete, normalmente relacionados con los métodos `del__`, que han afectado a Python desde que se introdujo el GC cíclico.

Ver también

PEP 442 – Finalización segura del objeto

  PEP escrito y aplicado por Antoine Pitrou.

### PEP 456: Algoritmo Hash seguro e intercambiable

PEP 456 es la continuación de un trabajo anterior de corrección de seguridad realizado en el algoritmo hash de Python para hacer frente a ciertos ataques DOS a los que pueden estar sujetas las APIs de cara al público respaldadas por búsquedas de diccionario. (El PEP unifica el código hash de CPython para facilitar que un empaquetador sustituya un algoritmo hash diferente, y cambia la implementación por defecto de Python a una implementación SipHash en plataformas que tienen un tipo de datos de 64 bits. Cualquier diferencia de rendimiento en comparación con el antiguo algoritmo FNV es trivial.

El PEP añade campos adicionales a la tupla con nombre `sys.hash_info` para describir el algoritmo hash en uso por el binario que se está ejecutando. Por lo demás, el PEP no altera ninguna de las APIs existentes de CPython.

### PEP 436: Clínica de Argumentación

«Argument Clinic» (PEP 436) es ahora parte del proceso de construcción de CPython y puede ser utilizado para simplificar el proceso de definición y mantenimiento de firmas precisas para builtins y módulos de extensión de la biblioteca estándar implementados en C.

Algunos módulos de extensión de la biblioteca estándar han sido convertidos para utilizar Argument Clinic en Python 3.4, y `pydoc` y `inspect` han sido actualizados en consecuencia.

Se espera que los metadatos de firma para la introspección programática se añadan a los callables adicionales implementados en C como parte de las versiones de mantenimiento de Python 3.4.

Nota

El PEP de Argument Clinic no está completamente actualizado con el estado de la implementación. Esto ha sido considerado aceptable por el director de la versión y el equipo de desarrollo del núcleo en este caso, ya que Argument Clinic no estará disponible como una API pública para el uso de terceros en Python 3.4.

Ver también

PEP 436 – La clínica de argumentos DSL

  PEP escrito y aplicado por Larry Hastings.

### Otros cambios en la API de construcción y C

- La nueva función `PyType_GetSlot()` ha sido añadida a la ABI estable, permitiendo la recuperación de punteros a funciones desde ranuras de tipos con nombre cuando se utiliza la API limitada. (Contribuido por Martin von Löwis en bpo-17162.)

- La nueva API de preinicialización `Py_SetStandardStreamEncoding()` permite a las aplicaciones que incrustan el intérprete de CPython forzar de forma fiable una codificación concreta y un manejador de errores para los flujos estándar. (Contribuido por Bastien Montagne y Nick Coghlan en bpo-16129.)

- La mayoría de las APIs de C de Python que no mutan los argumentos de cadena están ahora correctamente marcadas como aceptando `const char *` en lugar de `char *`. (Contribuido por Serhiy Storchaka en bpo-1772673.)

- Una nueva versión de shell de `python-config` puede ser utilizada incluso cuando un intérprete de python no está disponible (por ejemplo, en escenarios de compilación cruzada).

- `PyUnicode_FromFormat()` ahora soporta especificaciones de anchura y precisión para `%s`, `%A`, `%U`, `%V`, `%S` y `%R`. (Contribución de Ysj Ray y Victor Stinner en bpo-7330.)

- La nueva función `PyStructSequence_InitType2()` complementa la función existente `PyStructSequence_InitType()`. La diferencia es que devuelve `0` en caso de éxito y `-1` en caso de fallo.

- El código fuente de CPython puede ahora ser compilado usando las características de comprobación de sanidad de direcciones de las versiones recientes de GCC y clang: las falsas alarmas en el asignador de objetos pequeños han sido silenciadas. (Contribuido por Dhiru Kholia en bpo-18596.)

- La versión de Windows utiliza ahora Address Space Layout Randomization y Data Execution Prevention. (Contribuido por Christian Heimes en bpo-16632.)

- La nueva función `PyObject_LengthHint()` es el equivalente en la API de C de `operator.length_hint()`. (Contribuido por Armin Ronacher en bpo-16148.)

### Otras mejoras

- El python tiene una nueva option, `-I`, que hace que se ejecute en «modo aislado», lo que significa que `sys.path` no contiene ni el directorio del script ni el directorio `site-packages` del usuario, y todas las variables de entorno `PYTHON*` son ignoradas (implica tanto `-s` como `-E`). También pueden aplicarse otras restricciones en el futuro, con el objetivo de aislar la ejecución de un script del entorno del usuario. Esto es apropiado, por ejemplo, cuando se utiliza Python para ejecutar un script del sistema. En la mayoría de los sistemas POSIX puede y debe utilizarse en la línea `#!` de los scripts del sistema. (Contribuido por Christian Heimes en bpo-16499.)

- El completamiento de tabulaciones está ahora habilitado por defecto en el intérprete interactivo en los sistemas que soportan `readline`. El historial también está activado por defecto, y se escribe (y se lee) en el archivo `~/.python-history`. (Contribuido por Antoine Pitrou y Éric Araujo en bpo-5845.)

- La invocación del intérprete de Python con `--versión` ahora muestra la versión en la salida estándar en lugar de en el error estándar (bpo-18338). Se han realizado cambios similares en `argparse` (bpo-18920) y en otros módulos que tienen capacidades de invocación tipo script (bpo-18922).

- El instalador de CPython para Windows añade ahora `.py` a la variable `PATHEXT` cuando se registran las extensiones, permitiendo a los usuarios ejecutar un script de python en el símbolo del sistema de Windows con sólo escribir su nombre sin la extensión `.py`. (Contribuido por Paul Moore en bpo-18569.)

- Un nuevo objetivo `make` coverage-report construirá python, ejecutará el conjunto de pruebas, y generará un informe de cobertura HTML para el código base C utilizando `gcov` y lcov.

- La opción `-R` del conjunto de pruebas de regresión de python ahora también comprueba las fugas de asignación de memoria, utilizando `sys.getallocatedblocks()`. (Contribuido por Antoine Pitrou en bpo-13390.)

- `python -m` ahora funciona con paquetes de espacios de nombres.

- El módulo `stat` está ahora implementado en C, lo que significa que obtiene los valores de sus constantes de los archivos de cabecera de C, en lugar de tener los valores codificados en el módulo de python como ocurría anteriormente.

- La carga de múltiples módulos de python desde un único módulo del sistema operativo (`.so`, `.dll`) ahora funciona correctamente (antes devolvía silenciosamente el primer módulo de python del archivo). (Contribuido por Václav Šmilauer en bpo-16421.)

- Se ha añadido un nuevo opcode, `LOAD_CLASSDEREF`, para corregir un error en la carga de variables libres en los cuerpos de las clases que podía ser provocado por ciertos usos de __prepare__. (Contribuido por Benjamin Peterson en bpo-17853.)

- Victor Stinner identificó y corrigió una serie de fallos relacionados con MemoryError utilizando su herramienta `pyfailmalloc` basada en PEP 445 (bpo-18408, bpo-18520).

- El comando `pyvenv` acepta ahora la opción `--copies` para utilizar copias en lugar de enlaces simbólicos, incluso en sistemas en los que los enlaces simbólicos son los predeterminados. (Contribuido por Vinay Sajip en bpo-18807.)

- El comando `pyvenv` también acepta la opción `--without-pip` para suprimir el arranque automático de pip en el entorno virtual. (Contribuido por Nick Coghlan en bpo-19552 como parte de la implementación de PEP 453)

- El nombre de la codificación es ahora opcional en el valor establecido para la variable de entorno `PYTHONIOENCODING`. Esto hace posible establecer sólo el manejador de errores, sin cambiar la codificación por defecto. (Contribuido por Serhiy Storchaka en bpo-18818.)

- Las funciones del módulo `bz2`, `lzma` y `gzip` ahora soportan el modo `x` (creación exclusiva). (Contribución de Tim Heaney y Vajrasky Kok en bpo-19201, bpo-19222 y bpo-19223)

### Optimizaciones significativas

- El decodificador de UTF-32 es ahora entre 3 y 4 veces más rápido. (Contribuido por Serhiy Storchaka en bpo-14625.)

- Se ha reducido el coste de las colisiones de hash para los conjuntos. Cada sondeo de la tabla hash comprueba ahora una serie de pares clave/hash consecutivos y adyacentes antes de continuar haciendo sondeos aleatorios a través de la tabla hash. Esto aprovecha la localidad de la caché para que la resolución de colisiones sea menos costosa. El esquema de resolución de colisiones puede describirse como un híbrido de sondeo lineal y direccionamiento abierto. El número de sondeos lineales adicionales es por defecto de nueve. Esto puede cambiarse en tiempo de compilación definiendo LINEAR_PROBES con cualquier valor. Establezca LINEAR_PROBES=0 para desactivar completamente el sondeo lineal. (Contribuido por Raymond Hettinger en bpo-18771.)

- El intérprete comienza alrededor de 30% faster. Un par de medidas conducen a la aceleración. El intérprete carga menos módulos al iniciar, por ejemplo, los módulos `re`, `collections` y `locale` y sus dependencias ya no se importan por defecto. Se ha mejorado el módulo marshal para cargar más rápidamente el código Python compilado. (Contribución de Antoine Pitrou, Christian Heimes y Victor Stinner en bpo-19219, bpo-19218, bpo-19209, bpo-19205 y bpo-9548)

- `bz2.BZ2File` es ahora tan rápido o más que la versión de Python2 en la mayoría de los casos. `lzma.LZMAFile` también ha sido optimizado. (Contribuido por Serhiy Storchaka y Nadeem Vawda en bpo-16034)

- `random.getrandbits()` es un 20%-40% más rápido para enteros pequeños (el caso de uso más común). (Contribuido por Serhiy Storchaka en bpo-16674.)

- Al aprovechar el nuevo formato de almacenamiento de las cadenas, el decapado de las cadenas es ahora significativamente más rápido. (Contribución de Victor Stinner y Antoine Pitrou en bpo-15596.)

- Se ha resuelto un problema de rendimiento en `io.FileIO.readall()`. Esto afecta particularmente a Windows, y acelera significativamente el caso de canalizar cantidades significativas de datos a través de `subprocess`. (Contribuido por Richard Oudkerk en bpo-15758.)

- `html.escape()` es ahora 10 veces más rápido. (Contribuido por Matt Bryant en bpo-18020.)

- En Windows, ahora se utiliza el `VirtualAlloc` nativo en lugar del `malloc` de CRT en `obmalloc`. Los benchmarks artificiales muestran un ahorro de memoria de alrededor del 3%.

- `os.urandom()` now uses a lazily opened persistent file descriptor so as to avoid using many file descriptors when run in parallel from multiple threads. (Contributed by Antoine Pitrou in bpo-18756.)

## Obsoleto

Esta sección cubre varias APIs y otras características que han sido desaprobadas en Python 3.4, y que serán eliminadas en Python 3.5 o posterior. En la mayoría de los casos (pero no en todos), el uso de las APIs obsoletas producirá un `DeprecationWarning` cuando el intérprete se ejecute con las advertencias de obturación activadas (por ejemplo, usando `-Wd`).

### Desapariciones en la API de Python

- Como se menciona en PEP 451: Un tipo ModuleSpec para el sistema de importación, varios métodos y funciones de `importlib` están obsoletos: `importlib.find_loader()` se sustituye por `importlib.util.find_spec()`; `importlib.machinery.PathFinder.find_module()` se sustituye por `importlib.machinery.PathFinder.find_spec()`; `importlib.abc.MetaPathFinder.find_module()` se sustituye por `importlib.abc.MetaPathFinder.find_spec()`; `importlib.abc.PathEntryFinder.find_loader()` y `find_module()` se sustituyen por `importlib.abc.PathEntryFinder.find_spec()`; todos los métodos `xxxLoader` ABC `load_module` (`importlib.abc.Loader.load_module()`, `importlib.abc.InspectLoader.load_module()`, `importlib.abc.FileLoader.load_module()`, `importlib.abc.SourceLoader.load_module()`) ya no deberían implementarse, en su lugar los cargadores deberían implementar un método `exec_module` (`importlib.abc.Loader.exec_module()`, `importlib.abc.InspectLoader.exec_module()` `importlib.abc.SourceLoader.exec_module()`) y dejar que el sistema de importación se encargue del resto; y `importlib.abc.Loader.module_repr()`, `importlib.util.module_for_loader()`, `importlib.util.set_loader()`, y `importlib.util.set_package()` ya no son necesarios porque sus funciones son ahora manejadas automáticamente por el sistema de importación.

- El módulo `imp` está pendiente de ser eliminado. Para mantener la compatibilidad con las bases de código de Python 2/3, la eliminación del módulo no está programada actualmente.

- El módulo `formatter` está pendiente de desaprobación y está previsto que se elimine en Python 3.6.

- `MD5` como digestmod por defecto para la función `hmac.new()` está en desuso. Python 3.6 requerirá un nombre de compendio o constructor explícito como argumento digestmod.

- La clase interna `Netrc` en el módulo `ftplib` ha sido documentada como obsoleta en su docstring durante bastante tiempo. Ahora emite un `DeprecationWarning` y se eliminará por completo en Python 3.5.

- El argumento indocumentado endtime de `subprocess.Popen.wait()` no debería haber sido expuesto y es de esperar que no esté en uso; es obsoleto y muy probablemente será eliminado en Python 3.5.

- El argumento strict de `HTMLParser` está obsoleto.

- Las funciones `plistlib` `readPlist()`, `writePlist()`, `readPlistFromBytes()`, y `writePlistToBytes()` quedan obsoletas en favor de las correspondientes nuevas funciones `load()`, `dump()`, `loads()`, y `dumps()`. `Data()` queda obsoleta en favor de la utilización del constructor `bytes`.

- La clave `sysconfig` `SO` está obsoleta, ha sido sustituida por `EXT_SUFFIX`.

- El modo `U` aceptado por varias funciones `open` está obsoleto. En Python3 no hace nada útil, y debe ser reemplazado por usos apropiados de `io.TextIOWrapper` (si es necesario) y su argumento newline.

- El argumento parser de `xml.etree.ElementTree.iterparse()` ha quedado obsoleto, al igual que el argumento html de `XMLParser()`. Para prepararse para la eliminación de este último, todos los argumentos de `XMLParser` deben pasarse por palabra clave.

### Funciones obsoletas

- La ejecución de IDLE con la bandera `n` (sin subproceso) está obsoleta. Sin embargo, la función no se eliminará hasta que se resuelva el problema bpo-18823.

- El módulo site que añade un directorio «site-python» a sys.path, si existe, está obsoleto (bpo-19375).

## Removido

### Sistemas operativos que ya no son compatibles

Se ha eliminado la compatibilidad con los siguientes sistemas operativos en las herramientas de origen y de compilación:

- OS/2 (bpo-16135).

- Windows 2000 (changeset e52df05b496a).

- Sistemas Windows donde `COMSPEC` apunta a `command.com` (bpo-14470).

- VMS (bpo-16136).

### Eliminación de la API y de las funciones

Se han eliminado las siguientes APIs y características obsoletas y previamente obsoletas:

- Los directorios `Misc/TextMate` y `Misc/vim` no mantenidos han sido eliminados (ver la devguide para sugerencias sobre qué usar en su lugar).

- Se ha eliminado la macro makefile `SO` (se ha sustituido por las macros `SHLIB_SUFFIX` y `EXT_SUFFIX`) (bpo-16754).

- Se ha eliminado el campo `PyThreadState.tick_counter`; su valor no tiene sentido desde Python 3.2, cuando se introdujo el «nuevo GIL» (bpo-19199).

- `PyLoader` y `PyPycLoader` han sido eliminados de `importlib`. (Contribuido por Taras Lyapun en bpo-15641.)

- Se ha eliminado el argumento estricto de `HTTPConnection` y `HTTPSConnection`. Ya no se admiten las «respuestas simples» del estilo de HTTP 0.9.

- Los métodos getter y setter `urllib.request` obsoletos `add_data`, `has_data`, `get_data`, `get_type`, `get_host`, `get_selector`, `set_proxy`, `get_origin_req_host`, y `is_unverifiable` han sido eliminados (utilice en su lugar el acceso directo a atributos).

- Se ha eliminado el soporte para cargar el obsoleto `TYPE_INT64` de `marshal`. (Contribuido por Dan Riti en bpo-15480.)

- `inspect.Signature`: ahora se requiere que los parámetros sólo posicionales tengan un nombre válido.

- `object.__format__()` ya no acepta cadenas de formato no vacías, ahora lanza un `TypeError` en su lugar. El uso de una cadena no vacía ha sido desaprobado desde Python 3.2. Este cambio se ha hecho para evitar una situación en la que el código que antes funcionaba (pero era incorrecto) empezaba a fallar si un objeto ganaba un método __format__, lo que significa que su código puede ahora lanzar un `TypeError` si está usando un código de formato `s` con objetos que no tienen un método __format__ que lo maneje. Véase bpo-7994 para más información.

- `difflib.SequenceMatcher.isbjunk()` y `difflib.SequenceMatcher.isbpopular()` estaban obsoletos en la 3.2, y han sido eliminados: utilice `x en sm.bjunk` y `x en sm.bpopular`, donde sm es un objeto `SequenceMatcher` (bpo-13248).

### Limpieza del código

- Se ha eliminado la clase interna `Scanner` no utilizada y no documentada del módulo `pydoc`.

- Se ha eliminado el módulo privado y efectivamente inutilizado `_gestalt`, junto con las funciones privadas de `platform` `_mac_ver_lookup`, `_mac_ver_gstalt`, y `_bcd2str`, que sólo habrían sido llamadas en sistemas OSX muy estropeados (ver bpo-18393).

- Se han eliminado las copias codificadas de ciertas constantes `stat` que se incluían en el espacio de nombres del módulo `tarfile`.

## Adaptación a Python 3.4

Esta sección enumera los cambios descritos anteriormente y otras correcciones de errores que pueden requerir cambios en su código.

### Cambios en el comportamiento del comando “python”

- En un shell posix, establecer la variable de entorno `PATH` a un valor vacío es equivalente a no establecerla en absoluto. Sin embargo, establecer `PYTHONPATH` a un valor vacío era no equivalente a no establecerla en absoluto: establecer `PYTHONPATH` a un valor vacío era equivalente a establecerla a `.`, lo que lleva a confusión cuando se razona por analogía con el funcionamiento de `PATH`. El comportamiento ahora se ajusta a la convención posix para `PATH`.

- La salida [X refs, Y blocks] de una compilación de depuración (`--con-pydebug`) del intérprete de CPython está ahora desactivada por defecto. Se puede volver a activar usando la opción `-X showrefcount`. (Contribuido por Ezio Melotti en bpo-17323.)

- El comando python y la mayoría de los scripts de stdlib (así como `argparse`) ahora envían la información de `--version` a `stdout` en lugar de a `stderr` (para la lista de problemas, véase Otras mejoras más arriba).

### Cambios en la API de Python

- Los ABCs definidos en `importlib.abc` ahora lanzan la excepción apropiada o devuelven un valor por defecto en lugar de lanzar `NotImplementedError` a ciegas. Esto sólo afectará al código que llame a `super()` y que llegue hasta el ABC. Por compatibilidad, capture tanto `NotImplementedError` como la excepción apropiada según sea necesario.

- El tipo de módulo ahora inicializa los atributos `__package__` y `__loader__` a `None` por defecto. Para determinar si estos atributos se establecieron de forma retrocompatible, utilice, por ejemplo, `getattr(module, '__loader__', None) is not None`. (bpo-17115.)

- `importlib.util.module_for_loader()` ahora establece `loader__` y `__package__` incondicionalmente para soportar adecuadamente la recarga. Si no lo desea, tendrá que establecer estos atributos manualmente. Puede utilizar `importlib.util.module_to_load()` para la gestión de módulos.

- Importar ahora restablece los atributos relevantes (por ejemplo, `__name__`, `__loader__`, `__package__`, `__file__`, `__cached__`) incondicionalmente cuando se recarga. Tenga en cuenta que esto restablece un comportamiento anterior a la versión 3.3 en el sentido de que un módulo se vuelve a encontrar cuando se recarga (bpo-19413).

- Los paquetes congelados ya no establecen `ruta__` en una lista que contenga el nombre del paquete, ahora lo hacen en una lista vacía. El comportamiento anterior podía hacer que el sistema de importación hiciera algo incorrecto en las importaciones de submódulos si también había un directorio con el mismo nombre que el paquete congelado. La forma correcta de determinar si un módulo es un paquete o no es utilizar `hasattr(module, '__path__')` (bpo-18065).

- Los módulos congelados ya no definen el atributo `file__`. Es semánticamente incorrecto que los módulos congelados definan el atributo, ya que no se cargan desde ninguna ubicación explícita. Si necesitas saber que un módulo proviene de código congelado, puedes ver si el `__spec__.location` del módulo está configurado como `'frozen`, comprobar si el cargador es una subclase de `importlib.machinery.FrozenImporter`, o si la compatibilidad con Python 2 es necesaria, puedes utilizar `imp.is_frozen()`.

- `py_compile.compile()` ahora lanza `FileExistsError` si la ruta de archivo en la que escribiría es un enlace simbólico o un archivo no regular. Esto es para actuar como una advertencia de que la importación sobrescribirá esos archivos con un archivo regular sin importar el tipo de ruta de archivo que eran originalmente.

- `importlib.abc.SourceLoader.get_source()` ya no lanza `ImportError` cuando el código fuente que se carga provoca un `SyntaxError` o `UnicodeDecodeError`. Como `ImportError` está pensado para ser levantado sólo cuando el código fuente no puede ser encontrado pero debería, se sintió que se sobrepasaba/sobrecargaba ese significado cuando el código fuente es encontrado pero inadecuadamente estructurado. Si usted estaba atrapando ImportError antes y desea continuar ignorando los problemas de sintaxis o decodificación, atrape las tres excepciones ahora.

- `functools.update_wrapper()` y `functools.wraps()` ahora establecen correctamente el atributo `wrapped__` a la función que está siendo envuelta, incluso si esa función también tiene su atributo `wrapped__` establecido. Esto significa que los atributos `__wrapped__` ahora enlazan correctamente una pila de funciones decoradas en lugar de que cada atributo `__wrapped__` en la cadena haga referencia a la función más interna. Las bibliotecas de introspección que asumían que el comportamiento anterior era intencionado pueden utilizar `inspect.unwrap()` para acceder a la primera función de la cadena que no tenga el atributo `__wrapped__`.

- `inspect.getfullargspec()` ha sido reimplementado sobre `inspect.signature()` y por lo tanto maneja una variedad mucho más amplia de objetos llamables que en el pasado. Se espera que otras llamadas de módulos incorporados y de extensión obtengan metadatos de firma en el curso de la serie Python 3.4. El código que asume que `inspect.getfullargspec()` fallará en las llamadas que no son de Python puede necesitar ser ajustado en consecuencia.

- `importlib.machinery.PathFinder` ahora pasa el directorio de trabajo actual a los objetos en `sys.path_hooks` para la cadena vacía. Esto hace que `sys.path_importer_cache` nunca contenga `''`, por lo que iterar a través de `sys.path_importer_cache` basándose en `sys.path` no encontrará todas las claves. El `archivo__` de un módulo cuando se importa en el directorio de trabajo actual también tendrá ahora una ruta absoluta, incluso cuando se utiliza ``-m` con el intérprete (excepto para `__main__.__file__` cuando un script se ha ejecutado directamente utilizando una ruta relativa) (Contribuido por Brett Cannon en bpo-18416). se especifica en la línea de comandos) (bpo-18416).

- La eliminación del argumento estricto de `HTTPConnection` y `HTTPSConnection` cambia el significado de los argumentos restantes si los especifica posicionalmente en lugar de por palabra clave. Si ha prestado atención a las advertencias de desaprobación, su código ya debería especificar los argumentos adicionales mediante palabras clave.

- Las cadenas entre las sentencias `from __future__ import ...` ahora siempre lanzan un `SyntaxError`. Anteriormente, si no había un docstring principal, a veces se ignoraba una cadena intersticial. Esto hace que CPython cumpla con la especificación del lenguaje; Jython y PyPy ya lo hacían. (bpo-17434).

- `ssl.SSLSocket.getpeercert()` y `ssl.SSLSocket.do_handshake()` ahora lanzan un `OSError` con `ENOTCONN` cuando el `SSLSocket` no está conectado, en lugar del comportamiento anterior de lanzar un `AttributeError`. Además, `getpeercert()` lanzará un `ValueError` si el handshake aún no se ha realizado.

- `base64.b32decode()` ahora genera un `binascii.Error` cuando la cadena de entrada contiene caracteres que no son de tipo b32, en lugar de un `TypeError`. Este `TypeError` en particular se perdió cuando se convirtieron los otros `TypeError`. (Contribuido por Serhiy Storchaka en bpo-18011.) Nota: este cambio también se aplicó inadvertidamente en Python 3.3.3.

- El atributo `file` ahora se cierra automáticamente cuando la instancia `cgi.FieldStorage` creada se recoge de la basura. Si estaba sacando el objeto archivo por separado de la instancia `cgi.FieldStorage` y no mantenía la instancia viva, entonces debería almacenar toda la instancia `cgi.FieldStorage` o leer el contenido del archivo antes de que la instancia `cgi.FieldStorage` sea recogida de la basura.

- Llamar a `lectura` o `escritura` en un socket SSL cerrado ahora genera un informativo `ValueError` en lugar del anterior y más misterioso `AttributeError` (bpo-9177).

- `slice.indices()` ya no produce un `OverflowError` para valores enormes. Como consecuencia de esta corrección, `slice.indices()` ahora produce un `ValueError` si se le da una longitud negativa; antes devolvía valores sin sentido (bpo-14794).

- El constructor `complex`, a diferencia de las funciones `cmath`, aceptaba incorrectamente valores `float` si el método especial `__complex__` de un objeto devolvía uno. Ahora se produce un error `TypeError`. (bpo-16290.)

- El constructor `int` de las versiones 3.2 y 3.3 aceptaba erróneamente valores `float` para el parámetro base. Es poco probable que alguien esté haciendo esto, pero si es así, ahora lanzará un `TypeError` (bpo-16772).

- Los valores por defecto de los argumentos de palabras clave se evalúan ahora después de los valores por defecto de los argumentos de palabras clave normales, en lugar de antes. Esperemos que nadie haya escrito ningún código que dependa del comportamiento erróneo anterior (bpo-16967).

- Los estados de los hilos antiguos se borran ahora después de `fork()`. Esto puede hacer que se liberen algunos recursos del sistema que antes se mantenían vivos de forma incorrecta (por ejemplo, las conexiones a la base de datos mantenidas en el almacenamiento local del hilo). (bpo-17094.)

- Los nombres de los parámetros en los dicts de `anotaciones__` ahora se manipulan correctamente, de forma similar a ``__kwdefaults__`. (Contribuido por Yury Selivanov en bpo-20625.)

- `hashlib.hash.name` ahora siempre devuelve el identificador en minúsculas. Anteriormente, algunos hashes incorporados tenían nombres en mayúsculas, pero ahora que se trata de una interfaz pública formal, la denominación se ha hecho consistente (bpo-18532).

- Debido a que `unittest.TestSuite` ahora elimina las referencias a las pruebas después de su ejecución, los arneses de pruebas que reutilizan un `TestSuite` para volver a ejecutar un conjunto de pruebas pueden fallar. Los conjuntos de pruebas no deberían ser reutilizados de esta manera, ya que significa que el estado se mantiene entre las ejecuciones de las pruebas, rompiendo el aislamiento de las pruebas que `unittest` está diseñado para proporcionar. Sin embargo, si la falta de aislamiento se considera aceptable, el antiguo comportamiento puede restaurarse creando una subclase `TestSuite` que defina un método `_removeTestAtIndex` que no haga nada (ver `TestSuite.__iter__()`) (bpo-11798).

- `unittest` ahora utiliza `argparse` para el análisis de la línea de comandos. Hay ciertas formas de comando inválidas que solían funcionar y que ya no están permitidas; en teoría, esto no debería causar problemas de compatibilidad con versiones anteriores, ya que las formas de comando no permitidas no tenían ningún sentido y es poco probable que estén en uso.

- Las funciones `re.split()`, `re.findall()` y `re.sub()`, y los métodos `group()` y `groups()` de los objetos `match` ahora siempre devuelven un objeto bytes cuando la cadena a comparar es un bytes-like object. Anteriormente el tipo de retorno coincidía con el tipo de entrada, por lo que si su código dependía de que el valor de retorno fuera, por ejemplo, un `bytearray`, tendrá que cambiar su código.

- Las funciones de `audioop` ahora lanzan un error inmediatamente si se les pasa una cadena de entrada, en lugar de fallar aleatoriamente más tarde (bpo-16685).

- El nuevo argumento convert_charrefs de `HTMLParser` tiene por defecto el valor `False` por compatibilidad con versiones anteriores, pero con el tiempo se cambiará a `True`. Se recomienda añadir esta palabra clave, con el valor apropiado, a cualquier llamada de `HTMLParser` en su código (bpo-13633).

- Dado que el argumento digestmod de la función `hmac.new()` no tendrá en el futuro ningún valor por defecto, todas las llamadas a `hmac.new()` deben cambiarse para especificar explícitamente un digestmod (bpo-17276).

- Llamar a `sysconfig.get_config_var()` con la clave `SO`, o buscar `SO` en los resultados de una llamada a `sysconfig.get_config_vars()` está obsoleto. Esta clave debería ser reemplazada por `EXT_SUFFIX` o `SHLIB_SUFFIX`, dependiendo del contexto (bpo-19555).

- Cualquier llamada a las funciones `open` que especifique `U` debe ser modificada. `U` es ineficaz en Python3 y acabará dando un error si se utiliza. Dependiendo de la función, el equivalente a su antiguo comportamiento en Python2 puede conseguirse usando un argumento newline, o si es necesario envolviendo el flujo en `TextIOWrapper` para usar su argumento newline (bpo-15204).

- Si utilizas `pyvenv` en un script y deseas que pip no se instale, debes añadir `--without-pip` a tu invocación del comando.

- El comportamiento por defecto de `json.dump()` y `json.dumps()` cuando se especifica una sangría ha cambiado: ya no produce espacios finales después de las comas de separación al final de las líneas. Esto sólo importará si tiene pruebas que hacen comparaciones sensibles a los espacios en blanco de dicha salida (bpo-16333).

- `doctest` ahora busca doctests en las cadenas del módulo de extensión `__doc__`, por lo que si su descubrimiento de pruebas de doctest incluye módulos de extensión que tienen cosas que parecen doctests en ellos, puede ver fallos de prueba que nunca ha visto antes al ejecutar sus pruebas (bpo-3158).

- El módulo `collections.abc` ha sido ligeramente refactorizado como parte de las mejoras de inicio de Python. Como consecuencia de esto, ya no se da el caso de que al importar `collections` se importe automáticamente `collections.abc`. Si su programa dependía de la importación implícita (no documentada), tendrá que añadir un `importar colecciones.abc` explícitamente (bpo-20784).

### Cambios en la API de C

- `PyEval_EvalFrameEx()`, `PyObject_Repr()`, y `PyObject_Str()`, junto con algunas otras APIs internas de C, incluyen ahora una aserción de depuración que asegura que no se utilicen en situaciones en las que puedan descartar silenciosamente una excepción actualmente activa. En los casos en los que se espera y se desea descartar la excepción activa (por ejemplo, porque ya se ha guardado localmente con `PyErr_Fetch()` o se está sustituyendo deliberadamente por una excepción diferente), se necesitará una llamada explícita a `PyErr_Clear()` para evitar que se active la aserción cuando se invoquen estas operaciones (directa o indirectamente) y se ejecuten contra una versión de Python que esté compilada con las aserciones activadas.

- `PyErr_SetImportError()` ahora establece `TypeError` cuando su argumento msg no está establecido. Anteriormente sólo se devolvía `NULL` sin establecer ninguna excepción.

- El resultado de la llamada de retorno de `PyOS_ReadlineFunctionPointer` debe ser ahora una cadena asignada por `PyMem_RawMalloc()` o `PyMem_RawRealloc()`, o `NULL` si se ha producido un error, en lugar de una cadena asignada por `PyMem_Malloc()` o `PyMem_Realloc()` (bpo-16742)

- `PyThread_set_key_value()` ahora siempre establece el valor. En Python 3.3, la función no hacía nada si la clave ya existía (si el valor actual es un puntero no `NULL`).

- Se ha eliminado el campo `f_tstate` (estado del hilo) de la estructura `PyFrameObject` para corregir un error: véase bpo-14432 para conocer los motivos.

## Cambiado en 3.4.3

### PEP 476: Habilitar la verificación de certificados por defecto para los clientes http stdlib

`http.client` y los módulos que lo utilizan, como `urllib.request` y `xmlrpc.client`, ahora verificarán que el servidor presenta un certificado que está firmado por una CA en el almacén de confianza de la plataforma y cuyo nombre de host coincide con el nombre de host que se solicita por defecto, mejorando significativamente la seguridad de muchas aplicaciones.

Para las aplicaciones que requieren el antiguo comportamiento anterior, pueden pasar un contexto alternativo:

    import urllib.request
    import ssl

    # This disables all verification
    context = ssl._create_unverified_context()

    # This allows using a specific certificate for the host, which doesn't need
    # to be in the trust store
    context = ssl.create_default_context(cafile="/path/to/file.crt")

    urllib.request.urlopen("https://invalid-cert", context=context)