Qué hay de nuevo en 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:

Nuevos módulos de la biblioteca:

Mejora significativa de los módulos de la biblioteca:

Mejoras en la seguridad:

Mejoras en la implementación de CPython:

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:

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 ahora son weakly referenceable.

  • 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

A new option flag, FAIL_FAST, halts test running as soon as the first failure is detected. (Contributed by R. David Murray and Daniel Urban in 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.)

New module attribute DEFAULT_IGNORES provides the list of directories that are used as the default value for the ignore parameter of the dircmp() function. (Contributed by Eli Bendersky in 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() now supports a return value of NotImplemented from the underlying comparison function. (Contributed by Katie Miller in 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 son weakly referenceable. (Aportado por 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() supports two new flags on platforms that provide them, O_PATH (un-opened file descriptor), and O_TMPFILE (unnamed temporary file; as of 3.4.0 release available only on Linux systems with a kernel version of 3.11 or newer that have uapi headers). (Contributed by Christian Heimes in bpo-18673 and Benjamin Peterson, respectively.)

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 now has an API that is similar to the standard pattern for stdlib serialization protocols, with new load(), dump(), loads(), and dumps() functions. (The older API is now deprecated.) In addition to the already supported XML plist format (FMT_XML), it also now supports the binary plist format (FMT_BINARY). (Contributed by Ronald Oussoren and others in 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.)

On Linux kernel version 2.6.36 or later, there are also some new Linux specific constants: RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME, and RLIMIT_SIGPENDING. (Contributed by Christian Heimes in bpo-19324.)

On FreeBSD version 9 and later, there some new FreeBSD specific constants: RLIMIT_SBSIZE, RLIMIT_SWAP, and RLIMIT_NPTS. (Contributed by Claudiu Popa in 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

The socket module now supports the CAN_BCM protocol on platforms that support it. (Contributed by Brian Thorne in 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.

The AF_LINK constant is now available on BSD and 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.)

If OpenSSL 0.9.8 or later is available, SSLContext has a new attribute verify_flags that can be used to control the certificate verification process by setting it to some combination of the new constants VERIFY_DEFAULT, VERIFY_CRL_CHECK_LEAF, VERIFY_CRL_CHECK_CHAIN, or VERIFY_X509_STRICT. OpenSSL does not do any CRL verification by default. (Contributed by Christien Heimes in 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.)

The module supports new ST_MODE flags, S_IFDOOR, S_IFPORT, and S_IFWHT. (Contributed by Christian Hiemes in 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

La clase TestCase tiene un nuevo método, subTest(), que produce un gestor de contexto cuyo bloque with se convierte en una «subprueba». Este gestor de contexto permite que un método de prueba genere subpruebas dinámicamente, por ejemplo, llamando al gestor de contexto subTest dentro de un bucle. Por lo tanto, un solo método de prueba puede producir un número indefinido de pruebas identificadas y contadas por separado, todas las cuales se ejecutarán incluso si una o más de ellas fallan. Por ejemplo:

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.

The PEP adds additional fields to the sys.hash_info named tuple to describe the hash algorithm in use by the currently executing binary. Otherwise, the PEP does not alter any existing CPython APIs.

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

  • The python command has a new option, -I, which causes it to run in «isolated mode», which means that sys.path contains neither the script’s directory nor the user’s site-packages directory, and all PYTHON* environment variables are ignored (it implies both -s and -E). Other restrictions may also be applied in the future, with the goal being to isolate the execution of a script from the user’s environment. This is appropriate, for example, when Python is used to run a system script. On most POSIX systems it can and should be used in the #! line of system scripts. (Contributed by Christian Heimes in 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, compilará 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() ahora usa un descriptor de archivo persistente abierto de forma diferida para evitar el uso de muchos descriptores de archivo cuando se ejecuta en paralelo desde varios subprocesos. (Aportado por Antoine Pitrou en 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

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

  • Parameter names in __annotations__ dicts are now mangled properly, similarly to __kwdefaults__. (Contributed by Yury Selivanov in 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)