1 de abril de 2015
Bienvenido a Django 1.8!
Estas notas de lanzamiento cubren las nuevas características, así como algunos cambios que no son compatibles con versiones anteriores (Cambios incompatibles con la versión anterior en 1.8) que debes tener en cuenta al actualizar desde Django 1.7 o versiones más antiguas. También hemos comenzado el proceso de desactivación de algunas características (Características deprecadas en 1.8), y algunas características han llegado a su fin y han sido eliminadas.
Consulte la guía Cómo actualizar Django a una versión más reciente si estás actualizando un proyecto existente.
Django 1.8 ha sido designada como la segunda versión de largo plazo. Recibirá actualizaciones de seguridad durante al menos tres años después de su lanzamiento. El soporte para la versión LTS anterior, Django 1.4, terminará seis meses después del lanzamiento de Django 1.8.
Django 1.8 requiere Python 2.7, 3.2, 3.3, 3.4 o 3.5. Recomendamos y solo oficialmente apoyamos la última versión de cada serie.
Django 1.8 es la primera versión que soporta Python 3.5.
Debido a la finalización del apoyo de upstream para Python 3.2 en febrero de 2016, no probaremos Django 1.8.x en Python 3.2 después de finales de 2016.
Model._meta¶Django ahora tiene una API formalizada para Model._meta, proporcionando un método oficialmente respaldado para recuperar campos y filtrar campos según sus atributos.
El objeto Model._meta ha formado parte de Django desde los días de la «Eliminación mágica» pre-0.96 – simplemente no era una API oficial, estable. En reconocimiento a esto, hemos esforzado por mantener la compatibilidad hacia atrás con el antiguo punto final de la API donde sea posible. Sin embargo, los puntos finales de la API que no forman parte de la nueva API oficial han sido descontinuados y eventualmente se eliminarán.
Django 1.8 define una API estable para integrar motores de plantillas. Incluye el soporte incorporado para el lenguaje de plantillas Django y para Jinja2. Soporta la renderización de plantillas con múltiples motores dentro del mismo proyecto. Aprende más sobre las nuevas características en la guía de temas </topics/templates> y revisa las instrucciones de actualización en versiones antiguas de la documentación.
Se han integrado varias características de la biblioteca de terceros django-secure en Django. django.middleware.security.SecurityMiddleware proporciona varias mejoras de seguridad al ciclo de solicitud/respuesta. La nueva opción check --deploy te permite verificar tu archivo de configuración de producción para aumentar la seguridad de tu sitio.
Django ahora tiene un módulo con extensiones para características específicas de PostgreSQL, como ArrayField, HStoreField, Campos de rango, y la búsqueda unaccent. Una descripción detallada de las características está disponible en la documentación.
Django ahora tiene un UUIDField para almacenar identificadores únicos universales. Se almacena como el tipo de datos nativo uuid en PostgreSQL y como un campo de caracteres fijo de longitud en otros backends. Hay un campo de formulario correspondiente <django.forms.UUIDField>.
Django ahora tiene un DurationField para almacenar períodos de tiempo - modelados en Python por timedelta. Se almacena en el tipo de datos nativo interval en PostgreSQL, como INTERVAL DAY(9) TO SECOND(6) en Oracle, y como un bigint de microsegundos en otros backends. También se han mejorado las operaciones aritméticas relacionadas con fechas y horas en todos los backends. Hay un campo de formulario correspondiente <django.forms.DurationField>.
Las expresiones de consulta permiten crear, personalizar y componer expresiones SQL complejas. Esto ha habilitado que annotate acepte expresiones distintas a las agregadas. Las agregaciones ahora pueden referirse a múltiples campos, así como realizar aritmética similar a los objetos F(). order_by() también ha ganado la capacidad de aceptar expresiones.
Las expresiones condicionales permiten utilizar lógica if … elif … else dentro de las consultas.
También se incluye una colección de funciones del servidor con funcionalidades como Coalesce, Concat y Substr.
TestCase¶TestCase ha sido refactorizado para permitir la inicialización de datos en el nivel de clase utilizando transacciones y puntos de salvaguarda. Los backends de bases de datos que no admiten transacciones, como MySQL con el motor de almacenamiento MyISAM, todavía podrán ejecutar estos tests pero no aprovecharán las mejoras. Los tests se ejecutan ahora dentro de dos bloques atomic() anidados: uno para la clase completa y otro para cada test.
La función de método TestCase.setUpTestData() agrega la capacidad de configurar los datos de prueba en el nivel de clase. Utilizando esta técnica puede acelerar los tests en comparación con utilizar setUp().
El cargado de fijadores dentro de TestCase se realiza ahora una vez para todo TestCase.
django.contrib.admin¶ModelAdmin ahora tiene un método has_module_permission() que permite limitar el acceso al módulo en la página de índice del admin.
InlineModelAdmin ahora tiene una atributo show_change_link que admite mostrar un enlace a la forma de cambio del objeto inline.
Utiliza el nuevo django.contrib.admin.RelatedOnlyFieldListFilter en ModelAdmin.list_filter para limitar las opciones de list_filter a objetos relacionados que están atados a aquellos desde el ModelAdmin.
El método ModelAdmin.delete_view() muestra un resumen de los objetos que se van a eliminar en la página de confirmación de eliminación.
La biblioteca jQuery incorporada en el admin ha sido actualizada a la versión 1.11.2.
Ahora puedes especificar AdminSite.site_url para mostrar un enlace al sitio frontal.
Ahora puedes especificar ModelAdmin.show_full_result_count para controlar si se debe mostrar el recuento completo de objetos en una página administrada filtrada.
La traducción de los textos es la siguiente:
Puedes controlar quién puede acceder al sitio administrativo sobreescribiendo solo AdminSite.has_permission() y AdminSite.login_form. El template base.html tiene un nuevo bloque usertools que contiene el encabezado específico del usuario. Una nueva variable de contexto has_permission, que obtiene su valor de has_permission(), indica si el usuario puede acceder al sitio.
Las listas desplegables de claves foráneas ahora tienen botones para cambiar o eliminar objetos relacionados utilizando un popup.
django.contrib.admindocs¶Ahora se parsea reStructuredText en las docstrings de modelos.
django.contrib.auth¶Los backends de autorización pueden levantar PermissionDenied en has_perm() y has_module_perms() para interrumpir el control de permisos.
PasswordResetForm ahora tiene un método send_mail() que se puede sobreescribir para personalizar el correo electrónico a enviar.
El max_length de Permission.name ha sido aumentado de 50 a 255 caracteres. Por favor, ejecuta la migración delimitada por la base de datos.
USERNAME_FIELD y REQUIRED_FIELDS ahora admiten ForeignKeys.
Se ha aumentado el recuento de iteraciones por defecto para el algoritmo de hash de contraseña PBKDF2 en un 33%. Este cambio compatible con retrocesos no afectará a los usuarios que hayan sobrescrito django.contrib.auth.hashers.PBKDF2PasswordHasher para cambiar el valor por defecto.
django.contrib.gis¶Un nuevo serializador de GeoJSON está ahora disponible: GeoJSON serializer.
Ahora se permite incluir una subconsulta como argumento de búsqueda geográfica, por ejemplo City.objects.filter(point__within=Country.objects.filter(continent='Africa').values('mpoly')).
El backend SpatiaLite ahora admite agregados Collect y Extent cuando la versión del motor de base de datos es 3.0 o posterior.
Los comandos de inicialización CREATE EXTENSION postgis de PostGIS 2 y SELECT InitSpatialMetaData de SpatiaLite ahora se ejecutan automáticamente por migrate.
La interfaz GDAL ahora admite recuperar propiedades de archivos de datos raster (imagen): raster (image) data file.
Se han eliminado las compatibilidades para SpatialRefSys y GeometryColumns que cambiaron en Django 1.2.
Ahora se levantan excepciones GDAL relacionadas con GDALException. La antigua OGRException ha sido conservada por compatibilidad hacia atrás pero ya no debe usarse.
django.contrib.sesiones¶La cookie de sesión ahora se elimina después de que se llama a flush().
El nuevo atributo Sitemap.i18n permite generar un mapa del sitio basado en el LANGUAGES configuración.
django.contrib.sitios¶get_current_site() ahora busca el sitio actual según request.get_host() si la configuración SITE_ID no está definida.
El default Site creado cuando se ejecuta migrate ahora respeta la configuración de SITE_ID (en lugar de utilizar siempre pk=1).
La función incr() del backend django.core.cache.backends.locmem.LocMemCache es ahora thread-safe.
El parámetro max_age de la función django.core.signing.TimestampSigner.unsign() también acepta ahora un objeto datetime.timedelta.
El backend MySQL ya no elimina los microsegundos de los valores datetime, ya que MySQL 5.6.4 y superior admite segundos fraccionarios dependiendo de la declaración del campo datetime (cuando DATETIME incluye precisión fraccionaria mayor que 0). Las columnas de base de datos datetime creadas con Django 1.8 y MySQL 5.6.4 y superior admitirán microsegundos. Consulta las notas sobre bases de datos de MySQL <mysql-fractional-seconds> para obtener más detalles.
El backend MySQL ya no crea índices explícitos para claves foráneas cuando se utiliza el motor de almacenamiento InnoDB, ya que MySQL crea automáticamente los índices.
El backend Oracle ya no define la característica connection_persists_old_columns como True. En su lugar, Oracle incluirá ahora una cláusula para romper la caché al obtener la descripción de una tabla.
Los backends de correo electrónico :ref:` <topic-email-backends>` ahora admiten el protocolo del administrador de contexto para abrir y cerrar conexiones.
El backend SMTP de correo electrónico ahora admite la autenticación con keyfile y certfile utilizando las configuraciones EMAIL_SSL_CERTFILE y EMAIL_SSL_KEYFILE.
El backend SMTP EmailBackend ahora admite establecer el parámetro timeout con la configuración EMAIL_TIMEOUT.
EmailMessage y EmailMultiAlternatives ahora admiten el parámetro reply_to.
Storage.get_available_name() y Storage.save() ahora aceptan un argumento max_length para implementar restricciones de longitud máxima de nombre de archivo en el nivel de almacenamiento. Los nombres de archivo que exceden este argumento se truncarán. Esto previene un error de base de datos cuando se agrega un sufijo único a un largo nombre de archivo que ya existe en el almacenamiento. Consulte la nota de deprecación de storage-max-length-update sobre agregar este argumento a tus clases de almacenamiento personalizadas.
Los widgets de formulario ahora renderizan atributos con un valor de True o False como atributos booleanos HTML5.
El nuevo método has_error() permite comprobar si ha ocurrido un error específico.
Si se define el atributo required_css_class en un formulario, entonces los etiquetas <label> de los campos requeridos tendrán esta clase presente en sus atributos.
La renderización de errores no relacionados con campos en listas desordenadas (<ul>) ahora incluye nonfield en su lista de clases para distinguirlos de errores específicos de campo.
Field ahora acepta el argumento label_suffix, que sobrescribirá el sufijo de etiqueta del formulario. Esto permite personalizar el sufijo en una base por campo — anteriormente no era posible sobreescribir el sufijo de un formulario mientras se utilizaban atajos como {{ form.as_p }} en plantillas.
SelectDateWidget ahora acepta el argumento empty_label, que sobrescribirá la etiqueta de elección superior cuando DateField no es requerido.
Después de que un objeto UploadedFile de un campo de imagen se haya limpiado y validado, tendrá un atributo adicional image que contiene la instancia de Pillow Image utilizada para comprobar si el archivo era una imagen válida. También actualizará UploadedFile.content_type con el tipo de contenido de la imagen determinado por Pillow.
Puedes pasar un callable que devuelve una iterable de opciones cuando instancias un campo ChoiceField.
Los textos traducidos son:
La nueva propiedad query_pk_and_slug <django.views.generic.detail.SingleObjectMixin.query_pk_and_slug> de la clase SingleObjectMixin permite cambiar el comportamiento del método get_object() para que realice su búsqueda utilizando tanto la clave primaria como el slug.
El método get_form() de la clase FormMixin ya no requiere proporcionar una propiedad form_class. Si no se proporciona, form_class se establece en la clase obtenida mediante el método get_form_class().
Los placeholders en la propiedad success_url <django.views.generic.edit.ModelFormMixin.success_url> de la clase ModelFormMixin ahora admiten el sintaxis de formato de Python str.format(). La sintaxis legada %(<foo>)s todavía está soportada, pero se eliminará en Django 1.10.
La propiedad FORMAT_MODULE_PATH puede ser una lista de cadenas que representan rutas de módulos. Esto permite importar varios módulos de formatos desde diferentes aplicaciones reutilizables y también permite sobrescribir esos formatos personalizados en el proyecto Django principal.
La clase django.utils.log.AdminEmailHandler ahora tiene un método send_mail para hacerla más amigable con subclases.
Las conexiones a la base de datos se cierran siempre después de que una orden de comando de gestión llamada desde la línea de comandos haya terminado su trabajo.
Ahora también se descubren los comandos de paquetes alternativos como huevos.
La nueva opción –output del comando dumpdata permite especificar un archivo al que se escribirá la data serializada.
Las nuevas opciones –exclude y –exclude del comando makemessages y compilemessages, respectivamente, permiten excluir locales específicos del procesamiento.
compilemessages ahora tiene una opción --use-fuzzy o -f que incluye traducciones borrosas en los archivos compilados.
La opción loaddata --ignorenonexistent ahora ignora datos para modelos que ya no existen.
runserver utiliza ahora hilos demonios para una recarga más rápida.
inspectdb ahora imprime Meta.unique_together. También es capaz de introspeccionar AutoField en bases de datos MySQL y PostgreSQL.
Al llamar comandos de gestión con opciones utilizando call_command(), el nombre de la opción puede coincidir con el nombre de la opción de línea de comandos (sin las barras diagonales iniciales) o el nombre final del destino variable de la opción, pero en cualquier caso, la opción resultante recibida por el comando es ahora siempre el nombre dest especificado en la definición de la opción del comando (a condición de que el comando utilice el módulo argparse).
El comando dbshell ahora admite la configuración opcional de certificado SSL de MySQL (--ssl-ca).
La nueva opción makemigrations --name permite dar a las migraciones un nombre personalizado en lugar de uno generado.
El comando loaddata ahora previene la carga repetida de fijadores. Si FIXTURE_DIRS contiene duplicados o una ruta por defecto de directorio de fijador (app_name/fixtures), se levanta una excepción.
La nueva opción makemigrations --exit permite salir con un código de error si no se crean migraciones.
El nuevo comando showmigrations permite listar todas las migraciones y sus dependencias en un proyecto.
La propiedad CommonMiddleware.response_redirect_class te permite personalizar los redireccionamientos emitidos por el middleware.
Se registrará un mensaje de depuración en el logger django.request cuando un middleware levanta una excepción MiddlewareNotUsed en modo DEBUG.
La operación RunSQL puede manejar ahora parámetros pasados a las sentencias SQL.
Es posible tener migraciones (probablemente migraciones de datos) para aplicaciones sin modelos.
Las migraciones pueden ahora serializar administradores de modelos como parte del estado del modelo.
Se agregó un mechanismo genérico para manejar la desaparición de campos de modelos.
Se agregaron los métodos/atributos clase RunPython.noop() y RunSQL.noop para facilitar la reversibilidad de las operaciones RunPython y RunSQL.
Las operaciones de migración RunPython y RunSQL ahora llaman al método allow_migrate() de los routers de bases de datos. El router puede utilizar las nuevas argumentos app_label y hints para tomar una decisión de enrutamiento. Para aprovechar esta característica, debes actualizar el router a la nueva firma del método allow_migrate, consulta la sección de desaparición para obtener más detalles.
Django ahora registra como máximo 9000 consultas en connections.queries con el fin de prevenir un uso excesivo de memoria en procesos largos en modo depuración.
Ahora hay una opción del modelo Meta para definir un nombre relacionado por defecto <django.db.models.Options.default_related_name> para todos los campos relacionales de un modelo.
No se admite oficialmente la serialización de modelos y conjuntos de consultas entre diferentes versiones de Django (puede funcionar, pero no hay garantía). Se ha agregado una variable extra que especifica la versión actual de Django al estado serializado de los modelos y conjuntos de consultas, y Django lanza un RuntimeWarning cuando estos objetos se deserializan en una versión diferente a la que fueron serializados.
Se ha agregado el método Model.from_db() que utiliza Django siempre que los objetos se cargan utilizando ORM. El método permite personalizar el comportamiento de carga del modelo.
extra(select={...}) ahora permite escapar una secuencia literal %s usando %%s.
Se pueden registrar las vistas personalizadas <Custom Lookups</howto/custom-lookups>> utilizando un patrón de decorador.
La nueva atributo Transform.bilateral permite crear transformaciones bilaterales. Estas transformaciones se aplican tanto a lhs como a rhs cuando se utilizan en una expresión de búsqueda, lo que proporciona oportunidades para más sofisticadas búsquedas.
Los caracteres especiales SQL (, %, _) ahora se escapan correctamente cuando una búsqueda por patrón (por ejemplo, contains, startswith, etc.) se utiliza con una expresión F() como lado derecho. En esos casos, la escapada se realiza por el motor de base de datos, lo que puede llevar a consultas algo complejas involucrando llamadas a funciones REPLACE anidadas.
Puedes refrescar instancias de modelos utilizando Model.refresh_from_db().
Puedes obtener el conjunto de campos diferidos para un modelo utilizando Model.get_deferred_fields().
Los valores por defecto de los campos del modelo default se utilizan ahora cuando los campos primarios están configurados en None.
Exceptions desde las tuplas (receiver, exception) devueltas por Signal.send_robust() ahora tienen su traza de seguimiento adjunta como un atributo __traceback__.
Se ha agregado el argumento environ, que contiene la estructura del entorno WSGI desde la solicitud, al request_started signal.
Ahora puedes importar el setting_changed() signal de django.core.signals para evitar cargar django.test en situaciones no de prueba. Django ya no lo hace por sí mismo.
:Puede utilizar register como una función.
urlize ahora admite enlaces que incluyen solo el dominio y caracteres después del dominio superior (por ejemplo, djangoproject.com/ y djangoproject.com/download/).
urlize no trata los signos de exclamación al final de un dominio o su cadena de consulta como parte de la URL (la URL en e.g. 'djangoproject.com! es djangoproject.com)
Se ha agregado una clase locmem.Loader que carga plantillas Django desde un diccionario Python.
El now tag ahora puede almacenar su salida en una variable de contexto con la sintaxis habitual: {% now 'j n Y' as varname %}.
WSGIRequest ahora respeta rutas que comienzan con //.
El método HttpRequest.build_absolute_uri() ahora maneja correctamente las rutas que comienzan con //.
Si DEBUG es True y una solicitud levanta un error de tipo SuspiciousOperation, la respuesta se renderizará con una página de error detallada.
El argumento query_string de QueryDict ahora es opcional, por defecto se establece en None, por lo que ahora se puede instanciar un QueryDict vacío con QueryDict() en lugar de QueryDict(None) o QueryDict('').
Los atributos GET y POST de un objeto HttpRequest ahora son QueryDicts en lugar de diccionarios, y el atributo FILES ahora es un MultiValueDict. Esto pone a esta clase en línea con la documentación y con WSGIRequest.
Se agregó el atributo HttpResponse.charset.
WSGIRequestHandler ahora sigue las normas de RFC al convertir URI a IRI, utilizando uri_to_iri().
El método HttpRequest.get_full_path() ahora escapa los caracteres no seguros de la parte del camino de un Identificador de Recursos Uniforme (URI) correctamente.
La clase HttpResponse ahora implementa algunos métodos adicionales como getvalue() para que las instancias puedan usarse como objetos de flujo.
El nuevo método HttpResponse.setdefault() permite establecer una cabecera a menos que ya haya sido establecida.
Puedes usar la nueva clase FileResponse para streamear archivos.
El condition() decorador para el procesamiento condicional de vistas ahora admite la cabecera If-unmodified-since.
La clase RequestFactory.trace() <django.test.RequestFactory>` y la clase Client.trace() <django.test.Client.trace>` tienen métodos implementados, lo que permite crear solicitudes TRACE en tus pruebas.
Se agregó el argumento count a assertTemplateUsed(). Esto te permite afirmar que una plantilla se renderizó un número específico de veces.
La nueva aserción assertJSONNotEqual() te permite probar que dos fragmentos JSON no son iguales.
Se agregaron opciones al comando test (--keepdb), para preservar la base de datos de pruebas, (--reverse), para ejecutar los casos de prueba en orden inverso y (--debug-sql), para habilitar el registro de SQL para las pruebas fallidas.
Se agregó la atributo resolver_match a las respuestas del cliente de pruebas.
Se agregaron varias configuraciones que permiten personalizar los parámetros de espacio de nombres de tablas para Oracle: DATAFILE, DATAFILE_TMP, DATAFILE_MAXSIZE y DATAFILE_TMP_MAXSIZE.
El decorador override_settings() ahora puede afectar el router maestro en DATABASE_ROUTERS.
Se agregó soporte para subidas de archivos con objetos de archivo a los clientes de pruebas.
Ahora se utiliza una caché compartida cuando se prueba con una base de datos SQLite en memoria cuando se usa Python 3.4+ y SQLite 3.7.13+. Esto permite compartir la base de datos entre hilos.
URLValidator ahora admite direcciones IPv6, dominios Unicode y URLs que contienen datos de autenticación.
Advertencia
Además de los cambios descritos en esta sección, asegúrate de revisar el plan de desprecación para cualquier característica que haya sido eliminada. Si no has actualizado tu código dentro del plazo de desprecación de una determinada característica, su eliminación puede aparecer como un cambio incompatibles con la versión anterior.
Nota
Para permitir con mayor facilidad el uso en memoria de modelos, este cambio se rechazó en Django 1.8.4 y se reemplazó con una comprobación durante model.save(). Por ejemplo:
>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.save()
Traceback (most recent call last):
...
ValueError: save() prohibited to prevent data loss due to unsaved related object 'author'.
Una comprobación similar sobre la asignación a relaciones uno a uno fue eliminada en Django 1.8.5.
Asignar objetos no guardados a un ForeignKey, GenericForeignKey y OneToOneField ahora provoca una ValueError.
Previo a esto, la asignación de un objeto no guardado se ignoraba silenciosamente. Por ejemplo:
>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.author.save()
>>> book.save()
>>> Book.objects.get(name="Django")
>>> book.author
>>>
Ahora se levantará un error para evitar la pérdida de datos:
>>> book.author = Author(name="john")
Traceback (most recent call last):
...
ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.
Si requieres permitir la asignación de instancias no guardadas (el comportamiento antiguo) y no te preocupa la posibilidad de pérdida de datos (por ejemplo, nunca guardas los objetos en la base de datos), puedes deshabilitar esta comprobación utilizando el atributo ForeignKey.allow_unsaved_instance_assignment. (Este atributo se eliminó en 1.8.4 ya que ya no es relevante.)
Si has escrito una orden de comando de gestión personalizada que solo acepta argumentos posicionales y no especificaste la variable de comando args, podrías obtener un error como Error: argumentos no reconocidos: ..., ya que el análisis de variables ahora se basa en argparse que no acepta implícitamente los argumentos posicionales. Puedes hacer que tu comando sea compatible con versiones anteriores de Django simplemente estableciendo la variable de clase args. Sin embargo, si no tienes que mantener la compatibilidad con versiones anteriores de Django, es mejor implementar el nuevo método add_arguments() como se describe en Cómo crear comandos personalizados de django-admin.
El método para agregar argumentos personalizados a la orden de comando de administración test mediante el ejecutor de pruebas ha cambiado. Anteriormente, podías proporcionar una variable de clase option_list en el ejecutor de pruebas para agregar más argumentos (a la manera de optparse). Ahora para implementar el mismo comportamiento, debes crear un método de clase add_arguments(cls, parser) en el ejecutor de pruebas y llamar a parser.add_argument para agregar cualquier argumento personalizado, ya que ahora parser es una instancia de argparse.ArgumentParser.
Un nombre de campo que es más largo que la longitud del nombre de columna admitida por una base de datos puede crear problemas. Por ejemplo, con MySQL obtendrás una excepción al intentar crear la columna, y con PostgreSQL el nombre de la columna se trunca por la base de datos (puedes ver un aviso en los registros de PostgreSQL).
Se ha introducido un control de modelo para advertir mejor a los usuarios sobre esta situación antes de la creación real de tablas de bases de datos.
Si tienes un modelo existente en el que esta comprobación parece ser un falso positivo, por ejemplo en PostgreSQL donde el nombre ya estaba siendo truncado, simplemente utiliza db_column para especificar el nombre que se está utilizando.
La comprobación también se aplica a las columnas generadas en un modelo ManyToManyField.through implícito. Si te encuentras con un problema allí, utiliza through para crear un modelo explícito y luego especifica db_column en sus columna(s) según sea necesario.
Consultar lookups de modelos ahora comprueba si el objeto pasado es del tipo correcto y lanza un ValueError si no lo es. Anteriormente, Django no se preocupaba por si el objeto era del tipo correcto; simplemente utilizaba la propiedad de campo relacionado (por ejemplo id) para el lookup. Ahora, se lanza un error para prevenir lookups incorrectos:
>>> book = Book.objects.create(name="Django")
>>> book = Book.objects.filter(author=book)
Traceback (most recent call last):
...
ValueError: Cannot query "<Book: Django>": Must be "Author" instance.
EmailField.max_length a 254¶La antigua longitud por defecto de 75 caracteres no era capaz de almacenar todos los posibles formatos de direcciones de correo electrónico RFC3696/5321-compliant. Para poder almacenar todas las direcciones de correo electrónico válidas, la longitud por defecto se ha aumentado a 254 caracteres. Tendrás que generar y aplicar migraciones de base de datos para tus modelos afectados (o agregar max_length=75 si deseas mantener la longitud en tus campos actuales). Se incluye una migración para django.contrib.auth.models.User.email.
La traducción de los textos es la siguiente:
Esto también incluye el cese del soporte para PostGIS 1.3 y 1.4 ya que estas versiones no están soportadas en versiones posteriores a PostgreSQL 8.4.
Django ahora requiere el uso de Psycopg2 versión 2.4.5 o superior (o 2.5+ si deseas utilizar django.contrib.postgres).
El fin del período de soporte upstream se alcanzó en enero de 2012 para MySQL 5.0 y diciembre de 2013 para MySQL 5.1. Como consecuencia, Django 1.8 establece como versión mínima de MySQL que oficialmente admite la 5.5.
El fin del período de soporte upstream se alcanzó en julio de 2010 para Oracle 9.2, enero de 2012 para Oracle 10.1 y julio de 2013 para Oracle 10.2. Como consecuencia, Django 1.8 establece como versión mínima de Oracle que oficialmente admite la 11.1.
Las versiones anteriores de Django otorgaban el rol CONNECT y RESOURCE al usuario de prueba en Oracle. Estos roles han sido descontinuados, por lo que Django 1.8 utiliza los privilegios específicos subyacentes en su lugar. Esto cambia los privilegios requeridos del usuario principal para ejecutar pruebas (a menos que el proyecto esté configurado para evitar crear un usuario de prueba). Los privilegios exactos ahora requeridos se detallan en Notas de Oracle.
AbstractUser.last_login permite valores nulos.¶El texto traducido es el siguiente:
Si estás utilizando un modelo de usuario personalizado que hereda de AbstractUser, necesitarás ejecutar makemigrations y generar una migración para tu aplicación que contenga ese modelo. Además, si deseas establecer last_login en NULL para los usuarios que no han iniciado sesión, puedes ejecutar esta consulta:
from django.db import models
from django.contrib.auth import get_user_model
from django.contrib.auth.models import AbstractBaseUser
UserModel = get_user_model()
if issubclass(UserModel, AbstractBaseUser):
UserModel._default_manager.filter(last_login=models.F("date_joined")).update(
last_login=None
)
django.contrib.gis¶Se ha dejado de soportar GEOS 3.1 y GDAL 1.6.
Se ha dejado de soportar SpatiaLite < 2.4.
Las consultas específicas de GIS han sido refactorizadas para utilizar la API django.db.models.Lookup.
La representación predeterminada str de los objetos GEOSGeometry ha cambiado del formato WKT al EWKT (incluyendo el SRID). Como esta representación se utiliza en el marco de serialización, eso significa que la salida de dumpdata ahora contendrá el valor SRID de los objetos de geometría.
TemplateResponse ha sido llevada alineada con render¶El constructor TemplateResponse está diseñado para ser una sustitución directa del función render(). Sin embargo, tenía una incompatibilidad ligeramente menor, en que para TemplateResponse, los datos de contexto pasados en el diccionario de contexto podrían ser ocultados por los datos de contexto devueltos por los procesadores de contexto, mientras que para render era al revés. Esto fue un error, y el comportamiento de render es más apropiado, ya que permite a los procesadores de contexto globales ser sobrescritos localmente en la vista. Si estabas confiando en el hecho de que los datos de contexto en una TemplateResponse podrían ser sobrescritos utilizando un proceso de contexto, necesitarás cambiar tu código.
setUpClass / tearDownClass en casos de prueba¶Los decoradores override_settings() y modify_settings() ahora actúan a nivel de clase cuando se utilizan como decoradores de clase. Como consecuencia, cuando se sobreescribe setUpClass() o tearDownClass(), la implementación del super debería llamarse siempre.
La aplicación contribuyente formtools ha sido movida a un paquete separado y las páginas de documentación relevantes han sido actualizadas o eliminadas.
El nuevo paquete está disponible en GitHub y en PyPI.
Django cerraba previamente las conexiones de base de datos entre cada prueba dentro de una TestCase. Esto ya no es el caso, ya que Django ahora envuelve toda la TestCase en una transacción. Si algunas de tus pruebas dependían del comportamiento antiguo, deberías hacer que hereden de TransactionTestCase en su lugar.
django.template¶Si has estado confiando en APIs privadas expuestas en el módulo django.template, es posible que debas importarlas desde django.template.base en su lugar.
También se eliminaron las APIs privadas django.template.base.compile_string(), django.template.loader.find_template() y django.template.loader.get_template_from_string().
model de relaciones de modelos privados¶En versiones anteriores de Django, en un modelo con una relación de clave foránea inversa (por ejemplo), model._meta.get_all_related_objects() devolvía la relación como django.db.models.related.RelatedObject con el atributo model configurado para la fuente de la relación. Ahora, este método devuelve la relación como django.db.models.fields.related.ManyToOneRel (API privada RelatedObject ha sido eliminada), y el atributo model está configurado para el objetivo de la relación en lugar de la fuente. El modelo fuente es accesible en el atributo related_model en su lugar.
Considera este ejemplo del tutorial en Django 1.8:
>>> p = Poll.objects.get(pk=1)
>>> p._meta.get_all_related_objects()
[<ManyToOneRel: polls.choice>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Poll'>
>>> p._meta.get_all_related_objects()[0].related_model
<class 'polls.models.Choice'>
y compáralo con el comportamiento de versiones anteriores:
>>> p._meta.get_all_related_objects()
[<RelatedObject: polls:choice related to poll>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Choice'>
Para acceder al modelo fuente, puedes utilizar un patrón como este para escribir código que funcione tanto en Django 1.8 como en versiones anteriores:
for relation in opts.get_all_related_objects():
to_model = getattr(relation, "related_model", relation.model)
También ten en cuenta que get_all_related_objects() está deprecado en 1.8.
Los siguientes cambios en la API del backend de base de datos se documentan para ayudar a aquellos que escriben backends de terceros a actualizar su código:
Las clases BaseDatabaseXXX han sido movidas a django.db.backends.base. Por favor, importalas desde las nuevas ubicaciones:
from django.db.backends.base.base import BaseDatabaseWrapper
from django.db.backends.base.client import BaseDatabaseClient
from django.db.backends.base.creation import BaseDatabaseCreation
from django.db.backends.base.features import BaseDatabaseFeatures
from django.db.backends.base.introspection import BaseDatabaseIntrospection
from django.db.backends.base.introspection import FieldInfo, TableInfo
from django.db.backends.base.operations import BaseDatabaseOperations
from django.db.backends.base.schema import BaseDatabaseSchemaEditor
from django.db.backends.base.validation import BaseDatabaseValidation
Los atributos data_types, data_types_suffix y data_type_check_constraints han sido movidos de la clase DatabaseCreation a DatabaseWrapper.
El método SQLCompiler.as_sql() ahora toma un parámetro subquery (#24164).
El método BaseDatabaseOperations.date_interval_sql() ahora solo toma un parámetro timedelta.
django.contrib.admin¶AdminSite ya no acepta un argumento app_name y su atributo app_name ha sido eliminado. El nombre de la aplicación siempre es admin (a diferencia del nombre de instancia que todavía puedes personalizar utilizando AdminSite(name="...").
La traducción de los textos es la siguiente:
El método ModelAdmin.response_delete() ahora toma un segundo argumento llamado obj_id que es el identificador serializado utilizado para recuperar el objeto antes de la eliminación.
django.template.defaultfilters¶Para hacer que los filtros de plantilla integrados que devuelven HTML sean «seguros por defecto» al llamarlos en código Python, las siguientes funciones en django.template.defaultfilters han sido modificadas para escapar automáticamente su valor de entrada:
join
linebreaksbr
linebreaks_filter
linenumbers
unordered_list
urlize
urlizetrunc
Puedes revertir al comportamiento antiguo especificando autoescape=False si estás pasando contenido confiable. Esta modificación no tiene ningún efecto cuando se utilizan los correspondientes filtros en plantillas.
connections.queries es ahora un atributo de solo lectura.
Las conexiones a la base de datos se consideran iguales solo si son el mismo objeto. Ya no son hashables.
GZipMiddleware utilizaba a desactivar la compresión para algunos tipos de contenido cuando la solicitud era desde Internet Explorer, con el fin de trabajar alrededor de un bug en IE6 y versiones anteriores. Este comportamiento podía afectar el rendimiento en IE7 y posteriores. Fue eliminado.
URLField.to_python ya no agrega una barra diagonal final a URLs sin ruta.
La length filtro de plantilla ahora devuelve 0 para una variable indefinida, en lugar de una cadena vacía.
ForeignKey.default_error_message['invalid'] ha sido cambiado desde '%(model)s instance with pk %(pk)r does not exist.' a '%(model)s instance with %(field)s %(value)r does not exist.' Si estás utilizando este mensaje en tu propio código, por favor actualiza la lista de parámetros interpolados. Internamente, Django continuará proporcionando el parámetro pk en params para compatibilidad hacia atrás.
UserCreationForm.error_messages['duplicate_username'] ya no se utiliza. Si deseas personalizar ese mensaje de error, sobreescribilo en la forma utilizando la clave 'unique' en Meta.error_messages['username'] o, si tienes una forma de campo personalizada para 'username', utilizando la clave 'unique' en su argumento error_messages.
El bloque usertools en el template base.html de django.contrib.admin ahora requiere que la variable de contexto has_permission esté establecida. Si tienes alguna vista administrativa personalizada que utilice este template, actualiza a pasar AdminSite.has_permission() como valor para esta nueva variable o simplemente incluye AdminSite.each_context(request) en el contexto.
Los cambios internos se realizaron en el widget ClearableFileInput para permitir una mayor personalización. Se eliminó la atributo no documentado url_markup_template a favor de template_with_initial.
Para consistencia con otros proveedores principales, la locale en_GB ahora tiene lunes como primer día de la semana.
Se han eliminado los segundos de cualquier locale que los tuviera en TIME_FORMAT, DATETIME_FORMAT o SHORT_DATETIME_FORMAT.
La tamaño máximo por defecto de la tabla de espacio de pruebas Oracle ha aumentado de 300M (o 200M, antes de 1.7.2) a 500M.
reverse() y reverse_lazy() ahora devuelven cadenas Unicode en lugar de bytestrings.
Se eliminó el shim CacheClass de todos los backends de caché. Estas alias se proporcionaron para compatibilidad hacia atrás con Django 1.3. Si todavía las estás utilizando, por favor actualiza tu proyecto para utilizar el nombre real de la clase encontrada en la clave BACKEND del CACHES configuración.
Por defecto, call_command() ahora siempre salta el marco de comprobaciones (a menos que le pases skip_checks=False).
Cuando se itera sobre líneas, File ahora utiliza la convención de fin de línea universal PEP 278. Los siguientes son reconocidos como finalizando una línea: la convención Unix de fin de línea '\n', la convención Windows '\r\n' y la antigua Macintosh '\r'.
Los backends de caché Memcached MemcachedCache y PyLibMCCache eliminarán una clave si set() falla. Esto es necesario para asegurar que el almacenamiento de sesión cache_db siempre obtenga los datos de sesión más actuales.
Las APIs privadas override_template_loaders y override_with_test_loader en django.test.utils fueron eliminadas. Sobreescribe TEMPLATES con override_settings en su lugar.
Los textos traducidos son:
La clase HttpRequest ahora tiene una representación simplificada (por ejemplo, <WSGIRequest: GET '/somepath/'>). Esto no cambiará el comportamiento de la clase SafeExceptionReporterFilter.
Las vistas basadas en clases que utilizan ModelFormMixin lanzarán una excepción ImproperlyConfigured cuando se especifiquen tanto los atributos fields como form_class. Anteriormente, fields era ignorado silenciosamente.
Cuando sigue redirigiendo, el cliente de pruebas ahora lanza una excepción RedirectCycleError si detecta un bucle o supera el límite máximo de redirecciones (en lugar de pasar silenciosamente).
Las cadenas translatable que se establecen como parámetro default del campo se convierten en cadenas concretas más tarde, por lo que el tipo de retorno de Field.get_default() es diferente en algunos casos. No hay cambios en los valores predeterminados que son el resultado de una función.
GenericIPAddressField.empty_strings_allowed ahora es False. Los motores de base de datos que interpretan las cadenas vacías como nulos (solo Oracle entre los motores incluidos por Django) ya no convertirán los valores nulos en una cadena vacía. Esto es consistente con otros motores.
Cuando el atributo BaseCommand.leave_locale_alone es False, las traducciones ahora están desactivadas en lugar de forzar la locale «en-us». En el caso de que tus modelos contuvieran cadenas no inglesas y contaras con traducciones inglesas activadas en comandos de gestión, esto ya no sucederá. Es posible que se generen nuevas migraciones de base de datos (una vez) después de migrar a 1.8.
django.utils.translation.get_language() ahora devuelve None en lugar de LANGUAGE_CODE cuando las traducciones están desactivadas temporalmente.
Cuando una traducción no existe para un literal específico, el fallback ahora se toma del idioma LANGUAGE_CODE (en lugar de del mensaje msgid no traducido).
El campo name de la clase django.contrib.contenttypes.models.ContentType ha sido eliminado por una migración y reemplazado por una propiedad. Por lo tanto, ya no es posible consultar o filtrar un ContentType por este campo.
Be careful if you upgrade to Django 1.8 and skip Django 1.7. If you run
manage.py migrate --fake, this migration will be skipped and you’ll see
a RuntimeError: Error creating new content types. exception because the
name column won’t be dropped from the database. Use manage.py migrate
--fake-initial to fake only the initial migration instead.
La nueva opción migrate --fake-initial permite simular las migraciones iniciales. En 1.7, las migraciones iniciales se simulaban siempre automáticamente si todas las tablas creadas en una migración inicial ya existían.
Una aplicación sin migraciones con un ForeignKey a una aplicación con migraciones puede dar error de restricción de clave foránea al migrar la base de datos o ejecutar pruebas. En Django 1.7, esto podía fallar en silencio y resultar en una restricción faltante. Para resolver el error, agrega migraciones a la aplicación sin ellas.
django.db.models.options.Options¶Como parte de la formalización de la API Model._meta (de la clase django.db.models.options.Options), un número de métodos han sido deprecados y se eliminarán en Django 1.10:
get_all_field_names()
get_all_related_objects()
get_all_related_objects_with_model()
get_all_related_many_to_many_objects()
get_all_related_m2m_objects_with_model()
get_concrete_fields_with_model()
get_field_by_name()
get_fields_with_model()
get_m2m_with_model()
django.conf.urls.patterns()¶En los días antiguos de Django, se animaba a referenciar vistas como cadenas en urlpatterns:
urlpatterns = patterns(
"",
url("^$", "myapp.views.myview"),
)
and Django importaría mágicamente myapp.views.myview internamente y convertiría la cadena en una referencia a función real. Para reducir la repetición al referenciar muchas vistas del mismo módulo, la función patterns() toma un argumento inicial requerido prefix que se prefiere a todas las vistas como cadenas en ese conjunto de urlpatterns:
urlpatterns = patterns(
"myapp.views",
url("^$", "myview"),
url("^other/$", "otherview"),
)
En la era moderna, hemos actualizado el tutorial para recomendar en su lugar importar el módulo de vistas y referenciar directamente las funciones (o clases) de vista. Esto tiene varias ventajas, todas derivadas del hecho de que estamos utilizando Python normal en lugar de «Django String Magic»: los errores cuando se escribe mal el nombre de la vista son menos obscuros, los IDEs pueden ayudar con la autocompletación de nombres de vistas, etc.
Por lo tanto, estos días, el uso anterior del argumento prefix es mucho más probable que se escriba (y está mejor escrito) como:
from myapp import views
urlpatterns = patterns(
"",
url("^$", views.myview),
url("^other/$", views.otherview),
)
Así, patterns() sirve poco propósito y es un obstáculo cuando se enseña a nuevos usuarios (respondiendo a la pregunta del newbie «¿por qué necesito esta cadena vacía como primer argumento de patterns()?»). Por estas razones, estamos deprecando. Actualizar su código es tan simple como asegurarse de que urlpatterns sea una lista de instancias de django.conf.urls.url(). Por ejemplo:
from django.conf.urls import url
from myapp import views
urlpatterns = [
url("^$", views.myview),
url("^other/$", views.otherview),
]
view a django.conf.urls.url()¶Relacionado con el artículo anterior, referenciar vistas como cadenas en la función url() está deprecado. Pase la vista callable tal como se describe en la sección anterior.
django.core.context_processors¶Los procesadores de contexto de plantilla integrados han sido movidos a django.template.context_processors.
django.test.SimpleTestCase.urls¶La atributo SimpleTestCase.urls para especificar la configuración de URLconf en pruebas ha sido descontinuado y será eliminado en Django 1.10. Utiliza @override_settings(ROOT_URLCONF=...) en su lugar.
prefix a la función i18n_patterns()¶En relación con el elemento anterior, el argumento prefix a la función django.conf.urls.i18n.i18n_patterns() ha sido descontinuado. Simplemente pasa una lista de instancias de django.conf.urls.url() en su lugar.
for¶Usar un recuento incorrecto de valores desempaquetados en la etiqueta de plantilla for levantará una excepción en lugar de fallar silenciosamente en Django 1.10.
reverse() y url¶Revertir URLs por camino Python es una operación costosa ya que causa la importación del camino siendo revertido. Este comportamiento también ha resultado en una cuestión de seguridad. Utiliza los patrones de URL nombrados <naming-url-patterns>` para revertir en su lugar.
Si estás utilizando django.contrib.sitemaps, agrega el argumento name a la url que referencia la función django.contrib.sitemaps.views.sitemap()
from django.contrib.sitemaps.views import sitemap
url(
r"^sitemap\.xml$",
sitemap,
{"sitemaps": sitemaps},
name="django.contrib.sitemaps.views.sitemap",
)
para asegurar la compatibilidad cuando se elimina la reversión por camino Python en Django 1.10.
De manera similar para los mapas de sitios GIS, agrega name='django.contrib.gis.sitemaps.views.kml' o name='django.contrib.gis.sitemaps.views.kmz'.
Si estás utilizando una ruta de Python para la configuración LOGIN_URL o LOGIN_REDIRECT_URL, utiliza el nombre de la url() en su lugar.
Los módulos django.db.models.sql.aggregates y django.contrib.gis.db.models.sql.aggregates (ambos API privado), han sido deprecados como django.db.models.aggregates y django.contrib.gis.db.models.aggregates ahora también son responsables de la generación SQL. Los módulos antiguos serán eliminados en Django 1.10.
Si estabas utilizando los módulos antiguos, consulta Expresiones de Consulta para obtener instrucciones sobre cómo reescribir agregados personalizados utilizando la nueva API estable.
Los siguientes métodos y propiedades de django.db.models.sql.query.Query también han sido deprecados y los shim de compatibilidad hacia atrás serán eliminados en Django 1.10:
Query.aggregates, reemplazado por annotations.
Query.aggregate_select, reemplazado por annotation_select.
Query.add_aggregate(), reemplazado por add_annotation().
Query.set_aggregate_mask(), reemplazado por set_annotation_mask().
Query.append_aggregate_mask()``, reemplazado por append_annotation_mask().
Command.option_list¶Los comandos de administración ahora utilizan argparse en lugar de optparse para parsear los argumentos de línea de comandos pasados a los comandos. Esto también significa que la forma de agregar argumentos personalizados a los comandos ha cambiado: en lugar de extender la lista de clase option_list, debes ahora sobrescribir el método add_arguments() y agregar argumentos mediante argparse.add_argument(). Consulta este ejemplo para obtener más detalles.
django.core.management.NoArgsCommand¶La clase NoArgsCommand ahora está deprecada y se eliminará en Django 1.10. Utiliza BaseCommand en su lugar, que no acepta argumentos por defecto.
La opción --list del comando de administración migrate está deprecada y se eliminará en Django 1.10. Utiliza el comando showmigrations en su lugar.
cache_choices de ModelChoiceField y ModelMultipleChoiceField¶ModelChoiceField y ModelMultipleChoiceField tenían una opción no documentada e inprobada llamada cache_choices. Esta opción cacheaba consultas entre renderizaciones múltiples del mismo objeto de formulario. Esta opción está sujeta a una desprecación acelerada y se eliminará en Django 1.9.
django.template.resolve_variable()¶La función ha sido informalmente marcada como «Obsoleta» durante algún tiempo. Reemplaza resolve_variable(path, context) con django.template.Variable(path).resolve(context).
Proporcionaba la etiqueta de plantilla lorem, que ahora está incluida en las etiquetas integradas. Simplemente elimina django.contrib.webdesign de INSTALLED_APPS y {% load webdesign %} de tus plantillas.
error_message de django.forms.RegexField¶Proporcionaba compatibilidad hacia atrás para código pre-1.0, pero su funcionalidad es redundante. Utiliza Field.error_messages[“invalid”] en su lugar.
unordered_list¶Un formato de entrada más antiguo (pre-1.0), más restrictivo y verboso para el filtro de plantilla unordered_list ha sido marcado como obsoleto:
["States", [["Kansas", [["Lawrence", []], ["Topeka", []]]], ["Illinois", []]]]
Con la nueva sintaxis, esto se convierte en:
["States", ["Kansas", ["Lawrence", "Topeka"], "Illinois"]]
django.forms.Field._has_changed()¶Renombra este método a has_changed() eliminando el guión subrayado inicial. El nombre antiguo seguirá funcionando hasta Django 1.10.
is_admin_site de django.contrib.auth.views.password_reset()¶Es una opción heredada que ya no debería ser necesaria.
SubfieldBase¶django.db.models.fields.subclassing.SubfieldBase ha sido descontinuada y será eliminada en Django 1.10. Históricamente, se utilizaba para manejar campos donde era necesario la conversión de tipo al cargar desde la base de datos, pero no se utilizaba en llamadas a .values() o en agregados. Ha sido reemplazado por el método from_db_value().
La nueva aproximación no llama al método to_python() al asignar como era el caso con SubfieldBase. Si necesitas ese comportamiento, reimplementa la clase Creator desde el código fuente de Django en tu proyecto.
django.utils.checksums¶El módulo django.utils.checksums ha sido descontinuado y será eliminado en Django 1.10. La funcionalidad que proporcionaba (validación de checksum utilizando el algoritmo Luhn) estaba sin documentar y no se utilizaba en Django. El módulo ha sido movido a la django-localflavor paqueta (versión 1.1+).
InlineAdminForm.original_content_type_id¶La propiedad original_content_type_id en InlineAdminForm ha sido deprecada y se eliminará en Django 1.10. Históricamente, se utilizaba para construir la URL «ver en sitio». Esta URL ahora está accesible utilizando la propiedad absolute_url del formulario.
form_class de get_form() en FormMixin¶Las clases que heredan de FormMixin y sobrescriben el método get_form() deben asegurarse de proporcionar un valor por defecto para el argumento form_class ya que ahora es opcional.
get_template() con un Context¶El tipo de retorno de get_template() ha cambiado en Django 1.8: en lugar de una django.template.Template, devuelve una instancia Template cuyo tipo exacto depende del backend que la cargó.
Ambas clases proporcionan un método render(), sin embargo, la primera toma un django.template.Context como argumento mientras que la segunda espera un dict. Este cambio se impone a través de una ruta de deprecación para plantillas Django.
Todo esto también se aplica a select_template().
Template y Context en respuestas de plantilla¶Algunos métodos de SimpleTemplateResponse y TemplateResponse aceptaban objetos django.template.Context y django.template.Template como argumentos. Ahora deben recibir dict y objetos de plantilla dependientes del backend respectivamente.
Los textos traducidos son:
Consulte la documentación API de respuesta de plantilla <ref/template-response> para obtener más detalles.
dictionary y context_instance de las funciones de renderizado¶Las siguientes funciones ya no aceptarán los parámetros dictionary y context_instance en Django 1.10:
django.shortcuts.render()
django.shortcuts.render_to_response()
django.template.loader.render_to_string()
Utiliza el parámetro context en su lugar. Cuando se pasa dictionary como argumento posicional, lo que es la forma más común de hacerlo, no son necesarias cambios.
Si estás pasando un Context en context_instance, pasa un dict en el parámetro context en su lugar. Si estás pasando un RequestContext, pasa la solicitud por separado en el parámetro request.
dirs de las funciones de búsqueda de plantillas¶Los siguientes métodos ya no aceptarán un parámetro dirs para sobrescribir TEMPLATE_DIRS en Django 1.10:
django.shortcuts.render_to_response()
El parámetro no funcionaba de manera consistente a través de diferentes cargadores de plantillas y no funcionaba para las plantillas incluidas.
django.template.loader.BaseLoader¶django.template.loader.BaseLoader se renombró a django.template.loaders.base.Loader. Si has escrito un cargador de plantillas personalizado que hereda de BaseLoader, debes heredar Loader en su lugar.
django.test.utils.TestTemplateLoader¶La API privada django.test.utils.TestTemplateLoader se ha depreciado a favor de django.template.loaders.locmem.Loader y será eliminada en Django 1.9.
max_length en clases personalizadas de Storage¶Las subclases de Storage deben agregar max_length=None como parámetro a get_available_name() y/o save() si sobrescriben alguno de los métodos. El soporte para almacenamientos que no aceptan este argumento se eliminará en Django 1.10.
qn reemplazado por compiler¶En versiones anteriores de Django, varios métodos internos del ORM (principalmente los métodos as_sql) aceptaban un parámetro qn (para «citar nombre») que era una referencia a una función que citaba identificadores para enviarlos a la base de datos. En Django 1.8, ese argumento se ha renombrado a compiler y ahora es un instante completo de SQLCompiler. Para la compatibilidad hacia atrás, llamar a un instante de SQLCompiler realiza lo mismo que citar nombres que el parámetro qn utilizaba a hacer. Sin embargo, este shim de compatibilidad hacia atrás se ha depreciado inmediatamente: debes renombrar tus argumentos qn a compiler, y llamar a compiler.quote_name_unless_alias(...) donde anteriormente llamabas qn(...).
RedirectView.permanent¶El valor por defecto de la propiedad RedirectView.permanente cambiará de True a False en Django 1.9.
AuthenticationMiddleware sin SessionAuthenticationMiddleware¶django.contrib.auth.middleware.SessionAuthenticationMiddleware se agregó en Django 1.7. En Django 1.7.2, su funcionalidad se movió a auth.get_user() y, para compatibilidad hacia atrás, se habilitó solo si 'django.contrib.auth.middleware.SessionAuthenticationMiddleware' aparece en MIDDLEWARE_CLASSES.
En Django 1.10, la verificación de sesión estará habilitada sin importar si SessionAuthenticationMiddleware está habilitado (en cuyo caso SessionAuthenticationMiddleware ya no tendrá significado). Puedes agregarlo a tus MIDDLEWARE_CLASSES en algún momento antes que eso para opt-in. Por favor, lee las consideraciones de actualización primero.
django.contrib.sitemaps.FlatPageSitemap¶django.contrib.sitemaps.FlatPageSitemap se ha movido a django.contrib.flatpages.sitemaps.FlatPageSitemap. La ubicación de importación antigua está desaconsejada y será eliminada en Django 1.9.
ssi¶La traducción de los textos es la siguiente:
= como operador de comparación en el tag de plantilla {% if %}¶El uso de un signo igual con el tag de plantilla {% if %} para la prueba de igualdad estaba sin documentar y no probado. Ahora está obsoleto a favor de ==.
%(<foo>)s en ModelFormMixin.success_url¶La sintaxis legada %(<foo>)s en ModelFormMixin.success_url está obsoleta y será eliminada en Django 1.10.
GeoQuerySet¶Los métodos agregados collect(), extent(), extent3d(), make_line(), y unionagg() están obsoletos y deben ser reemplazados por sus equivalentes basados en funciones (Collect, Extent, Extent3D, MakeLine, y Union).
allow_migrate del router de bases de datos¶La firma del allow_migrate() método de los routers de bases de datos ha cambiado de allow_migrate(db, model) a allow_migrate(db, app_label, model_name=None, **hints).
Cuando se establece model_name, el valor que anteriormente se daba mediante la argumento posicional model ahora puede encontrarse dentro del diccionario de hints bajo la clave 'model'.
Después de cambiar a la nueva firma, el router también será llamado por las operaciones RunPython y RunSQL.
Estas características han llegado al final de su ciclo de deprecación y se eliminan en Django 1.8. Consulte Características obsoletas en 1.6 para obtener detalles, incluyendo cómo eliminar el uso de estas características.
django.contrib.comments está eliminada.
Las siguientes APIs de gestión de transacciones están eliminadas:
TransactionMiddleware
los decoradores y administradores de contexto autocommit, commit_on_success y commit_manually, definidos en django.db.transaction
las funciones commit_unless_managed y rollback_unless_managed, también definidas en django.db.transaction
la configuración TRANSACTIONS_MANAGED
Los marcadores de plantilla cycle y firstof auto-escapan sus argumentos.
La configuración SEND_BROKEN_LINK_EMAILS está eliminada.
La clase django.middleware.doc.XViewMiddleware está eliminada.
Se ha eliminado el alias Model._meta.module_name.
Las compatibilidades de retroceso introducidas para renombrar los métodos del conjunto de consultas get_query_set y similares están eliminadas. Esto afecta las siguientes clases: BaseModelAdmin, ChangeList, BaseCommentNode, GenericForeignKey, Manager, SingleRelatedObjectDescriptor y ReverseSingleRelatedObjectDescriptor.
Las compatibilidades de retroceso introducidas para renombrar los atributos ChangeList.root_query_set y ChangeList.query_set están eliminadas.
Se han eliminado django.views.defaults.shortcut y django.conf.urls.shortcut.
Se ha eliminado el soporte para la biblioteca de imágenes de Python (PIL).
Se han eliminado las siguientes APIs privadas:
django.db.backend
django.db.close_connection()
django.db.backends.creation.BaseDatabaseCreation.set_autocommit()
La traducción de los textos es la siguiente:
django.db.transaction.managed()
django.forms.widgets.RadioInput se ha eliminado.
El módulo django.test.simple y la clase django.test.simple.DjangoTestSuiteRunner se han eliminado.
El módulo django.test._doctest se ha eliminado.
La configuración CACHE_MIDDLEWARE_ANONYMOUS_ONLY se ha eliminado. Esta modificación afecta tanto a django.middleware.cache.CacheMiddleware como a django.middleware.cache.UpdateCacheMiddleware, a pesar de la falta de una advertencia de desprecación en la clase última.
La utilización del string Hold down «Control», o «Command» en un Mac, para seleccionar más de uno. predefinido para sobreescribir o agregar a la help_text proporcionada por el usuario en los campos de modelos ManyToMany ya no se realiza por Django ni en el nivel de modelo ni en el de formularios.
Los métodos Model._meta.get_(add|change|delete)_permission se han eliminado.
La clave de sesión django_language ya no se lee para compatibilidad con versiones anteriores.
Los Mapas Sitemaps geográficos se han eliminado (django.contrib.gis.sitemaps.views.index y django.contrib.gis.sitemaps.views.sitemap).
Los textos traducidos son:
may 31, 2026