Novedades de Python 3.4
***********************

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

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

Ver también: **PEP 429** -- Calendario de lanzamiento de Python 3.4


Resumen -- Puntos destacados del lanzamiento
============================================

Nuevas características de sintaxis:

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

Otras novedades:

* pip debe estar siempre disponible (**PEP 453**).

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

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

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

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

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

Nuevos módulos de la biblioteca:

* "asyncio": Nueva API provisional para IO asíncrona (**PEP 3156**).

* "ensurepip": Bootstrapping the pip installer (**PEP 453**).

* "enum": Soporte para tipos de enumeración (**PEP 435**).

* "pathlib": Rutas del sistema de archivos orientadas a objetos (**PEP
  428**).

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

* "statistics": Una básica numerically stable statistics library
  (**PEP 450**).

* "tracemalloc": Trace Python memory allocations (**PEP 454**).

Mejora significativa de los módulos de la biblioteca:

* Funciones genéricas de despacho único en "functools" (**PEP 443**).

* Nuevo "pickle" protocolo 4 (**PEP 3154**).

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

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

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

* La API del módulo "ipaddress" ha sido declarada estable

Mejoras en la seguridad:

* Algoritmo hash seguro e intercambiable (**PEP 456**).

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

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

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

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

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

* Soporte de TLSv1.1 y TLSv1.2 para "ssl".

* Recuperación de certificados del soporte del almacén de certificados
  del sistema Windows para "ssl".

* Soporte SNI (Server Name Indication) del lado del servidor para
  "ssl".

* La clase "ssl.SSLContext" tiene un mucho que mejorar.

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

Mejoras en la implementación de CPython:

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

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

* Asignadores de memoria configurable (**PEP 445**).

* Consultorio de argumentos (**PEP 436**).

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


Nuevas Funciones
================


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


Puesta en marcha de pip por defecto
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

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

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

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

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

Nota:

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


Cambios en la documentación
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

Ver también:

  **PEP 453** -- Arranque explícito de pip en instalaciones de Python
     PEP escrito por Donald Stufft y Nick Coghlan, implementado por
     Donald Stufft, Nick Coghlan, Martin von Löwis y Ned Deily.


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

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

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

* "os.get_inheritable()", "os.set_inheritable()"

* "os.get_handle_inheritable()", "os.set_handle_inheritable()"

* "socket.socket.get_inheritable()", "socket.socket.set_inheritable()"

Ver también:

  **PEP 446** -- Hacer que los descriptores de archivo recién creados
  no sean heredables
     PEP escrito y aplicado por Victor Stinner.


Mejoras en el manejo de códecs
------------------------------

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

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

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

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

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

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

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

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

   >>> import codecs

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

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

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

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

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

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

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

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

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

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


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

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

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


Otros cambios de lenguaje
-------------------------

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

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

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

* Los objetos del módulo son ahora "weakref"'able.

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

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

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

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

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

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

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

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

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

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


Nuevos Módulos
==============


asyncio
-------

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

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

Ver también:

  **PEP 3156** -- Soporte de IO asíncrono reiniciado: el módulo
  "asyncio
     PEP redactado y ejecutado por Guido van Rossum.


ensurepip
---------

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

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

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


enum
----

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

Ver también:

  **PEP 435** -- Añadir un tipo Enum a la biblioteca estándar de
  Python
     PEP escrito por Barry Warsaw, Eli Bendersky y Ethan Furman,
     implementado por Ethan Furman.


pathlib
-------

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

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

Ver también:

  **PEP 428** -- El módulo pathlib -- rutas del sistema de archivos
  orientadas a objetos
     PEP escrito y aplicado por Antoine Pitrou.


selectores
----------

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


estadísticas
------------

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

Ver también:

  **PEP 450** -- Añadir un módulo de estadísticas a la biblioteca
  estándar
     PEP escrito y aplicado por Steven D'Aprano


tracemalloc
-----------

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

* Rastrear dónde se asignó un objeto

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

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

Ver también:

  **PEP 454** -- Añade un nuevo módulo tracemalloc para rastrear las
  asignaciones de memoria de Python
     PEP escrito y aplicado por Victor Stinner


Módulos mejorados
=================


abc
---

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

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


aifc
----

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

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

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


argparse
--------

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


audioop
-------

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

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

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


base64
------

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

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


colecciones
-----------

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


colorsys
--------

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


contextlib
----------

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

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

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


dbm
---

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


dis
---

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

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

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

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

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

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

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

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

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

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


doctest
-------

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

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

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


email
-----

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

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

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

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


archivoecmp
-----------

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

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


functools
---------

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

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

Ver también:

  **PEP 443** -- Funciones genéricas de despacho único
     PEP escrito e implementado por Łukasz Langa.

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

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


gc
--

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


glob
----

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


hashlib
-------

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

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


hmac
----

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

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

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


html
----

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

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

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


http
----

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

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


idlelib y IDLE
--------------

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


importlib
---------

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

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

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

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

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

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

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

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


inspeccionar
------------

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

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

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

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

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


dirección IP
------------

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

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


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

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

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

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

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


mariscal
--------

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


mmap
----

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


multiprocesamiento
------------------

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

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

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

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


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

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

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


os
--

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

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

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

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

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


pdb
---

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

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


pepinillo
---------

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

Ver también:

  **PEP 3154** -- Protocolo Pickle 4
     PEP escrito por Antoine Pitrou e implementado por Alexandre
     Vassalotti.


plistlib
--------

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


poplib
------

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


pprint
------

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

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


pty
---

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


pydoc
-----

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

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

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

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


re
--

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

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


recurso
-------

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

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

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


seleccionar
-----------

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

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


estante
-------

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


shutil
------

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


smtpd
-----

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


smtplib
-------

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


enchufe
-------

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

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

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

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

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


sqlite3
-------

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


ssl
---

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

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

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

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

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

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

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

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

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

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


stat
----

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

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


struct
------

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


subproceso
----------

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

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


sunau
-----

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

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

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

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


sys
---

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

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


tarfile
-------

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


textwrap
--------

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


roscado
-------

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


traceback
---------

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


tipos
-----

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


urllib
------

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

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

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

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


unittest
--------

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

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

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

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

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

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

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

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

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

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

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


venv
----

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

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


onda
----

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

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

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

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


weakref
-------

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

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

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


xml.etree
---------

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

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


archivo zip
-----------

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

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


Cambios en la implementación de CPython
=======================================


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

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

Ver también:

  **PEP 445** -- Añadir nuevas APIs para personalizar los asignadores
  de memoria de Python
     PEP escrito y aplicado por Victor Stinner.


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

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

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

Ver también:

  **PEP 442** -- Finalización segura del objeto
     PEP escrito y aplicado por Antoine Pitrou.


PEP 456: Algoritmo Hash seguro e intercambiable
-----------------------------------------------

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

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


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

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

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

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

Nota:

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

Ver también:

  **PEP 436** -- La clínica de argumentos DSL
     PEP escrito y aplicado por Larry Hastings.


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

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

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

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

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

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

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

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

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

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


Otras mejoras
-------------

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

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

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

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

* A new "make" target coverage-report will build python, run the test
  suite, and generate an HTML coverage report for the C codebase using
  "gcov" and lcov.

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

* "python -m" ahora funciona con paquetes de espacios de nombres.

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

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

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

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

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

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

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

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


Optimizaciones significativas
-----------------------------

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

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

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

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

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

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

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

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

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

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


Obsoleto
========

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


Desapariciones en la API de Python
----------------------------------

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

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

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

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

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

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

* El argumento *strict* de "HTMLParser" está obsoleto.

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

* La clave "sysconfig" "SO" está obsoleta, ha sido sustituida por
  "EXT_SUFFIX".

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

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


Funciones obsoletas
-------------------

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

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


Removido
========


Sistemas operativos que ya no son compatibles
---------------------------------------------

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

* OS/2 (bpo-16135).

* Windows 2000 (changeset e52df05b496a).

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

* VMS (bpo-16136).


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

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

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

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

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

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

* Se ha eliminado el argumento *estricto* de "HTTPConnection" y
  "HTTPSConnection".  Ya no se admiten las "respuestas simples" del
  estilo de HTTP 0.9.

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

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

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

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

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


Limpieza del código
-------------------

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

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

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


Adaptación a Python 3.4
=======================

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


Cambios en el comportamiento del comando 'python'
-------------------------------------------------

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

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

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


Cambios en la API de Python
---------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Cambios en la API de C
----------------------

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

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

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

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

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


Cambiado en 3.4.3
=================


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

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

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

   import urllib.request
   import ssl

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

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

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