23 de marzo de 2011
Bienvenido a Django 1.3!
Casi un año en elaboración, Django 1.3 incluye varias características nuevas y bastantes correcciones de errores y mejoras a las características existentes. Estas notas de lanzamiento cubren las nuevas características de 1.3, así como algunos cambios incompatibles con la versión anterior que debes tener en cuenta al actualizar desde Django 1.2 o versiones anteriores.
El foco de Django 1.3 ha estado principalmente en resolver solicitudes de características menores, pero eso no ha impedido que algunas características nuevas bastante significativas lleguen, incluyendo:
Un marco para escribir vistas basadas en clases.
Soporte integrado para utilizar las facilidades de registro de Python.
Contribución de soporte para el manejo fácil de archivos estáticos`_.
El marco de pruebas de Django ahora admite (y viene con una copia de) la biblioteca unittest2.
Donde sea posible, las nuevas características se introducen de manera compatible con la versión anterior según nuestra política de estabilidad de API . Como resultado de esta política, Django 1.3 inicia el proceso de desactivación para algunas características.
La liberación de Django 1.2 fue notable por tener la primera modificación en la política de compatibilidad con Python de Django; antes de Django 1.2, Django soportaba cualquier versión 2.x de Python desde 2.3 en adelante. A partir de Django 1.2, se elevó el requisito mínimo a Python 2.4.
Django 1.3 continúa soportando Python 2.4, pero será la última serie de liberaciones de Django que lo haga; comenzando con Django 1.4, la versión mínima de Python soportada será 2.5. Un documento que describe nuestra cronología completa para despreciar Python 2.x y pasar a Python 3.x se publicará poco después de la liberación de Django 1.3.
Django 1.3 agrega un marco que permite utilizar una clase como vista. Esto significa que puedes componer una vista a partir de una colección de métodos que pueden ser sobrescritos y personalizados para proporcionar vistas comunes de datos sin tener que escribir demasiado código.
Se han proporcionado analogías de todas las viejas vistas genericas basadas en funciones, junto con una clase base de vista completamente genérica que se puede utilizar como base para aplicaciones reutilizables que pueden ser fácilmente extendidas.
Consultar la documentación sobre vistas genericas basadas en clases para obtener más detalles. También hay un documento para ayudarte a convertir tus vistas genericas basadas en funciones a vistas basadas en clases.
Django 1.3 agrega soporte a nivel de marco para el módulo logging de Python. Esto significa que ahora puedes configurar y controlar fácilmente el registro como parte de tu proyecto Django. Se han agregado un número de manejadores de registro y llamadas de registro a la propia códigos de Django, además – sobre todo, los correos electrónicos de error enviados en caso de un error HTTP 500 ahora se manejan como actividad de registro. Consultar la documentación sobre la interfaz de registro de Django para obtener más detalles.
Django 1.3 viene con una nueva aplicación contributiva – django.contrib.staticfiles – para ayudar a los desarrolladores a manejar los archivos de medios estáticos (imágenes, CSS, JavaScript, etc.) que se necesitan para renderizar una página web completa.
En versiones anteriores de Django, era común colocar activos estáticos en MEDIA_ROOT junto con archivos subidos por el usuario, y servirlos ambos en MEDIA_URL. Parte del propósito de la introducción de la aplicación staticfiles es hacer que sea más fácil mantener los archivos estáticos separados de los archivos subidos por el usuario. Los activos estáticos deben ir ahora en subdirectorios static/ de tus aplicaciones o en otros directorios de activos estáticos listados en STATICFILES_DIRS, y se servirán en STATIC_URL.
Ver la documentación de referencia del aplicación para obtener más detalles o aprender a gestionar archivos estáticos.
unittest2¶Python 2.7 introdujo algunas importantes modificaciones en la biblioteca unittest, agregando algunas características extremadamente útiles. Para asegurarse de que cada proyecto Django pueda aprovechar estas nuevas características, Django incluye una copia de unittest2, una copia de la biblioteca unittest de Python 2.7, backportada para compatibilidad con Python 2.4.
Para acceder a esta biblioteca, Django proporciona el módulo de alias django.utils.unittest. Si estás utilizando Python 2.7, o si has instalado localmente unittest2, Django mapeará el alias hacia la versión instalada de la biblioteca unittest. De lo contrario, Django utilizará su propia versión embutida de unittest2.
Usa simplemente:
from django.utils import unittest
dondequiera que históricamente hubieras utilizado:
import unittest
Si deseas seguir utilizando la biblioteca base unittest, puedes hacerlo – pero no obtendrás ninguna de las nuevas características agradables de unittest2.
Usuarios de Python 2.5 y superior pueden utilizar ahora funciones de gestión de transacciones como administradores de contexto. Por ejemplo:
with transaction.autocommit():
...
ForeignKey y OneToOneField ahora aceptan un argumento on_delete para personalizar el comportamiento cuando se elimina el objeto referenciado. Anteriormente, las eliminaciones siempre eran cascadas; ahora están disponibles alternativas como establecer nulo, establecer por defecto, establecer en cualquier valor, proteger o no hacer nada.
Para obtener más información, consulta la documentación de :attr:`~django.db.models.ForeignKey.on_delete`.
Para las cadenas de traducción con significado ambiguo, puedes utilizar ahora la función pgettext para especificar el contexto de la cadena.
Y si solo deseas agregar alguna información para traductores, también puedes agregar comentarios de traductor especiales en la fuente.
Para obtener más información, vea Marcadores de contexto y Comentarios para traductores.
A veces puede ser beneficioso permitir a los decoradores o middleware modificar la respuesta después de que ha sido construida por la vista. Por ejemplo, podrías querer cambiar el template utilizado o poner datos adicionales en el contexto.
Sin embargo, no puedes (fácilmente) modificar el contenido de un objeto HttpResponse básico después de que ha sido construido. Para superar esta limitación, Django 1.3 agrega una nueva clase TemplateResponse. A diferencia de los objetos HttpResponse básicos, los objetos TemplateResponse retienen los detalles del template y contexto que fue proporcionado por la vista para computar la respuesta. El resultado final de la respuesta no se computa hasta que sea necesario, más tarde en el proceso de respuesta.
Para obtener más detalles, consulta la documentación sobre la clase TemplateResponse.
Django 1.3 ve la introducción de varias mejoras a la infraestructura de caché de Django.
Primero, Django ahora admite múltiples caches con nombres. De la misma manera que Django 1.2 introdujo el soporte para múltiples conexiones de bases de datos, Django 1.3 permite utilizar el nuevo parámetro CACHES para definir múltiples conexiones de cache con nombres.
En segundo lugar, se han agregado a la API del cache las siguientes funcionalidades: versioning, prefixeo site-wide y transformación.
Terceramente, la creación de claves de cache se ha actualizado para tener en cuenta la cadena de consulta del request en las solicitudes GET.
Finalmente, se ha agregado el soporte para pylibmc a la backend de cache memcached.
Para más detalles, consulte la documentación sobre caching en Django.
Si proporcionas un backend de autenticación personalizado con supports_inactive_user establecido en True, una instancia de usuario inactivo verificará el backend para los permisos. Esto es útil para centralizar aún más la gestión de permisos. Consulte la documentación sobre autenticación para obtener más detalles.
El conjunto de pruebas de GeoDjango ahora se incluye cuando se ejecuta el conjunto de pruebas de Django con runtests.py al utilizar backends de bases de datos espaciales <spatial-backends>`.
MEDIA_URL y STATIC_URL deben terminar en una barra diagonal.¶Anteriormente, el parámetro MEDIA_URL solo requería una barra diagonal si contenía un sufijo más allá del nombre de dominio.
Un trailing slash es ahora obligatorio para la configuración MEDIA_URL y la nueva configuración de STATIC_URL, siempre que no esté en blanco. Esto garantiza una forma consistente de combinar rutas en plantillas.
Las configuraciones del proyecto que proporcionan cualquiera de las dos configuraciones sin un trailing slash ahora levantarán una PendingDeprecationWarning.
En Django 1.4, la misma condición levantará una DeprecationWarning, y en Django 1.5 levantará una excepción ImproperlyConfigured.
Django 1.1 y 1.2 agregaron muchos elementos importantes a Django, como el soporte para múltiples bases de datos, la validación de modelos y un marco de mensajes basado en sesión. Sin embargo, este foco en características importantes vino a costa de muchas características más pequeñas.
Para compensar esto, el proceso de desarrollo de Django 1.3 se ha centrado en agregar muchas características más pequeñas y solicitadas durante mucho tiempo. Estas incluyen:
Herramientas mejoradas para acceder y manipular el objeto Site actual en el marco de sitios :doc:` </ref/contrib/sites>`.
Una fábrica de solicitudes RequestFactory para simular solicitudes en pruebas.
Una nueva afirmación de prueba – assertNumQueries() – que facilita la prueba de la actividad de base de datos asociada con una vista.
Soporte para consultas que abarcan relaciones en el filtro de lista del administrador list_filter.
Soporte para cookies HttpOnly.
mail_admins() y mail_managers() ahora admiten la fácil adición de contenido HTML a los mensajes.
EmailMessage admite ahora CC’s.
Los correos electrónicos de errores incluyen ahora más detalles y formateo del error de página de servidor de depuración.
simple_tag() acepta ahora un argumento takes_context, lo que facilita escribir simples etiquetas de plantilla que requieren acceso al contexto de la plantilla.
Una nueva render() – una alternativa a django.shortcuts.render_to_response() que proporciona por defecto un RequestContext.
Soporte para combinar expresiones F con valores de timedelta al recuperar o actualizar valores de la base de datos.
Antes de Django 1.2.5, el sistema de prevención CSRF de Django eximía las solicitudes AJAX de la verificación CSRF; debido a problemas de seguridad informados a nosotros, sin embargo, todas las solicitudes están ahora sujetas a la verificación CSRF. Consulta la documentación de Django sobre CSRF para detalles sobre cómo manejar la verificación CSRF en solicitudes AJAX.
Antes de Django 1.2.5, la interfaz administrativa de Django permitía filtrar en cualquier campo o relación del modelo – no solo aquellos especificados en list_filter – mediante manipulación de la cadena de consulta. Debido a problemas de seguridad informáticos reportados a nosotros, sin embargo, los argumentos de búsqueda por cadena de consulta en el administrador deben ser para campos o relaciones especificadas en list_filter o date_hierarchy.
En versiones anteriores de Django, cuando se eliminaba una instancia de modelo que contenía un campo FileField, el propio campo FileField se encargaba de eliminar el archivo desde el almacenamiento backend. Esto abría la puerta a varios escenarios de pérdida de datos, incluyendo transacciones anuladas y campos en modelos diferentes que referenciaban el mismo archivo. En Django 1.3, cuando un modelo se elimina no se llama al método delete() del campo FileField. Si necesita limpiar archivos huérfanos, deberá manejarlo usted mismo (por ejemplo, con una orden de comando de gestión personalizada que puede ejecutarse manualmente o programada para ejecutarse periódicamente mediante e.g. cron).
El widget de formulario PasswordInput, destinado a usarse con campos de formulario que representan contraseñas, acepta un argumento booleano render_value indicando si enviar su datos nuevamente al navegador cuando se muestra un formulario enviado con errores. Antes de Django 1.3, este argumento tenía el valor por defecto True, lo que significaba que la contraseña enviada se volvería a enviar al navegador como parte del formulario. Los desarrolladores que deseaban agregar una pizca de seguridad adicionales excluyendo ese valor del formulario redisplayed podían instanciar un PasswordInput pasando render_value=False .
Sin embargo, debido a la naturaleza sensible de las contraseñas, Django 1.3 toma este paso automáticamente; el valor por defecto de render_value ahora es False, y los desarrolladores que desean que el valor de contraseña se devuelva al navegador en una solicitud con errores (el comportamiento anterior) deben indicarlo explícitamente. Por ejemplo:
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(render_value=True))
Django 1.3 incluye ahora un widget de formulario ClearableFileInput además del FileInput. ClearableFileInput renderiza con una casilla de verificación para eliminar el valor del campo (si el campo tiene un valor y no es requerido); FileInput no proporcionaba ninguna forma de eliminar un archivo existente desde un FileField.
ClearableFileInput ahora es el widget predeterminado para un FileField, por lo que las formas existentes que incluyen FileField sin asignar un widget personalizado deberán tener en cuenta la posible casilla de verificación extra en el resultado de renderizado del formulario.
Para volver al renderizado anterior (sin la capacidad de eliminar el FileField), utilice el widget FileInput en lugar de ClearableFileInput. Por ejemplo, en una forma ModelForm para un modelo hipotético Document con un campo FileField llamado document:
from django import forms
from myapp.models import Document
class DocumentForm(forms.ModelForm):
class Meta:
model = Document
widgets = {"document": forms.FileInput}
Antes de Django 1.3, la tabla de base de datos utilizada por el backend de base de datos para la aplicación sesiones no tenía una índice en la columna expire_date. Como resultado, las consultas basadas en fechas sobre la tabla de sesiones – como la consulta necesaria para eliminar sesiones antiguas – serían muy lentas si hubiera muchas sesiones.
Si tienes un proyecto existente que utiliza el backend de sesión de base de datos, no debes hacer nada para adaptarte a este cambio. Sin embargo, podrías obtener una mejora significativa en rendimiento si manualmente agregas la nueva índice a la tabla de sesiones. El SQL que agrega la índice se puede encontrar ejecutando el comando administrativo sqlindexes:
python manage.py sqlindexes sessions
Django ha proporcionado (y aplicado) históricamente una lista de palabrotas. La aplicación de comentarios ha aplicado esta lista de palabrotas, impidiendo que las personas enviaran comentarios que contuvieran alguna de esas palabrotas.
Desafortunadamente, la técnica utilizada para implementar esta lista de palabrotas era lamentablemente ingenua y propensa al problema Scunthorpe. Mejorar el filtro incorporado para solucionar este problema requeriría un esfuerzo significativo, y ya que el procesamiento de lenguaje natural no es el dominio normal de un framework web, hemos «solucionado» el problema haciendo la lista de palabras prohibidas una lista vacía.
Si deseas restaurar el comportamiento antiguo, simplemente coloca en tu archivo de configuración una variable PROFANITIES_LIST que incluya las palabras que desees prohibir (ver el commit que implementó este cambio si deseas ver la lista de palabras que se prohibió históricamente). Sin embargo, si evitar palabrotas es importante para ti, te aconsejaríamos buscar una mejor y menos ingenua solución al problema.
Django 1.3 introduce los siguientes cambios incompatibles con la retrocompatibilidad en sabores locales:
Canadá (ca) – La provincia «Terranova y Labrador» ha actualizado su código de provincia a «NL», en lugar del antiguo «NF». Además, el territorio de Yukón ha corregido su código de provincia a «YT», en lugar de «YK».
Indonesia (id) – La provincia «Nanggroe Aceh Darussalam (NAD)» ha sido eliminada de la lista de provincias en favor del nuevo nombre oficial «Aceh (ACE)».
Estados Unidos de América (us) – La lista de «estados» utilizada por USStateField se ha ampliado para incluir códigos postales de las Fuerzas Armadas. Esto es incompatible con el pasado si estabas confiando en que USStateField no los incluía.
En Django 1.3 se modifica ligeramente el comportamiento de la creación de FormSet. Históricamente, la clase no hacía distinción entre no pasar datos y pasar un diccionario vacío. Esto era inconsistente con el comportamiento en otras partes del marco. A partir de 1.3, si pasas un diccionario vacío, FormSet levantará una ValidationError.
Por ejemplo, con un FormSet:
>>> class ArticleForm(Form):
... title = CharField()
... pub_date = DateField()
...
>>> ArticleFormSet = formset_factory(ArticleForm)
el siguiente código levantará una ValidationError:
>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']
si necesitas instanciar un FormSet vacío, no pasa los datos o utiliza None:
>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)
Anteriormente, un llamable en una plantilla solo se llamaría automáticamente como parte del proceso de resolución de variables si era recuperado mediante búsqueda de atributos. Esto era una inconsistencia que podría dar lugar a comportamiento confuso y poco útil:
>>> Template("{{ user.get_full_name }}").render(Context({"user": user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({"full_name": user.get_full_name}))
u'<bound method User.get_full_name of <...
Esto ha sido resuelto en Django 1.3 - el resultado en ambos casos será u'Joe Bloggs'. Aunque el comportamiento anterior no era útil para un lenguaje de plantillas diseñado para diseñadores web, y nunca fue intencionalmente admitido, es posible que algunas plantillas puedan estar rotas por este cambio.
Django proporciona hooks de SQL personalizados como una forma de inyectar SQL manualmente en el proceso de sincronización del servidor de bases de datos. Uno de los posibles usos de este SQL personalizado es insertar datos en tu base de datos. Si tu SQL personalizado contiene INSERT declaraciones, esas inserciones se realizarán cada vez que se sincronice tu base de datos. Esto incluye la sincronización de cualquier base de datos de prueba creada cuando ejecutas un conjunto de pruebas.
Sin embargo, en el proceso de probar Django 1.3, se descubrió que esta característica nunca funcionó completamente como se anunciaba. Cuando se utilizan motores de bases de datos que no admiten transacciones o cuando se utiliza una TransactionTestCase, los datos insertados mediante SQL personalizado no serán visibles durante el proceso de prueba.
Desafortunadamente, no había forma de rectificar este problema sin introducir incompatibilidad hacia atrás. En lugar de dejar que los datos insertados por SQL personalizado estén en un estado incierto, Django ahora aplica la política de que los datos insertados mediante SQL personalizado no serán visibles durante el proceso de prueba.
Este cambio solo afecta al proceso de prueba. Puedes seguir utilizando SQL personalizado para cargar datos en tu base de datos de producción como parte del proceso syncdb. Si requieres que los datos existan durante las condiciones de prueba, deberás insertarlos usando fijaciones de prueba, o mediante el método setUp() de tu caso de prueba.
Se ha trabajado en simplificar, racionalizar y documentar adecuadamente el algoritmo utilizado por Django en tiempo de ejecución para construir traducciones a partir de las diferentes traducciones encontradas en disco, es decir:
Para literales translatables encontrados en código Python y plantillas (“django” dominio de gettext):
Se han cambiado las prioridades de las traducciones incluidas con aplicaciones listadas en la configuración INSTALLED_APPS. Para proporcionar un comportamiento consistente con otras partes de Django que también utilizan dicha configuración (plantillas, etc.), ahora, al construir la traducción que se hará disponible, las aplicaciones listadas primero tienen mayor precedencia que las listadas más tarde.
Ahora es posible sobreescribir las traducciones embarcadas con aplicaciones utilizando la configuración LOCALE_PATHS, cuyas traducciones ahora tienen mayor precedencia que las de las aplicaciones de INSTALLED_APPS. También se ha modificado la prioridad relativa entre los valores listados en esta configuración, por lo que los caminos listados primero tienen mayor precedencia que los listados más tarde.
La subcarpeta locale del directorio que contiene las configuraciones, que suele coincidir con y se conoce como el directorio de proyecto, está siendo deprecada en esta versión como fuente de traducciones. (la precedencia de estas traducciones es intermedia entre aplicaciones y traducciones de LOCALE_PATHS). Consulte la sección correspondiente de características obsoletas de este documento.
Para literales translatables encontrados en código JavaScript (“djangojs” dominio de gettext):
De manera similar a las traducciones del dominio 'django': Ahora es posible sobreescribir las traducciones embarcadas con aplicaciones utilizando la configuración LOCALE_PATHS. Estas traducciones tienen mayor precedencia que las de los paquetes Python pasados a la vista javascript_catalog(). Los caminos listados primero tienen mayor precedencia que los listados más tarde.
Las traducciones bajo la subcarpeta locale del directorio de proyecto nunca han sido tenidas en cuenta para las traducciones de JavaScript y siguen en la misma situación considerando la deprecación de tal ubicación.
When utilizando transacciones administradas – es decir, cualquier cosa menos el modo de autocomit por defecto – es importante cuando una transacción está marcada como «sucia». Las transacciones sucias se comiten mediante el decorador commit_on_success o el middleware django.middleware.transaction.TransactionMiddleware, y commit_manually las fuerza a cerrarse explícitamente; las transacciones limpias «pasan de largo», lo que significa que suelen ser rechazadas al final de una solicitud cuando la conexión se cierra.
Hasta Django 1.3, las transacciones solo estaban marcadas como sucias cuando Django estaba consciente de alguna operación modificadora realizada en ellas; es decir, ya sea que algún modelo fuera guardado, se realizarara alguna actualización o eliminación en masa o el usuario llamara explícitamente a transaction.set_dirty(). En Django 1.3, una transacción está marcada como sucia cuando cualquier operación de base de datos es realizada.
Como resultado de este cambio, ya no necesitas marcar explícitamente una transacción como sucia cuando ejecutes SQL crudo o utilices un SELECT modificador de datos. Sin embargo, sí necesitarás cerrar explícitamente cualquier transacción de lectura que esté siendo administrada utilizando commit_manually(). Por ejemplo:
@transaction.commit_manually
def my_view(request, name):
obj = get_object_or_404(MyObject, name__iexact=name)
return render_to_response("template", {"object": obj})
Antes de Django 1.3, esto funcionaría sin errores. Sin embargo, bajo Django 1.3, esto levantará un TransactionManagementError porque la operación de lectura que recupera la instancia MyObject deja la transacción en un estado sucio.
Antes de Django 1.3, los usuarios inactivos podían solicitar un correo electrónico de restablecimiento de contraseña y restablecer su contraseña. En Django 1.3, los usuarios inactivos recibirán el mismo mensaje que un cuenta no existente.
from_email¶La vista django.contrib.auth.views.password_reset() ahora acepta un parámetro from_email, que se pasa al método save() del formulario de restablecimiento de contraseña como argumento clave. Si estás utilizando esta vista con un formulario personalizado de restablecimiento de contraseña, entonces necesitarás asegurarte de que el método save() de tu formulario acepte este argumento clave.
Django 1.3 deprecia algunas características de versiones anteriores. Estas características todavía están soportadas, pero serán gradualmente eliminadas en los próximos ciclos de lanzamiento.
Los textos traducidos son:
En Django 1.4, estas advertencias se convertirán en una DeprecationWarning, que no es silenciosa. En Django 1.5, el soporte para estas características será removido por completo.
Ver también
Para obtener más detalles, consulte la documentación Django’s release process y nuestro deprecation timeline.
mod_python¶La biblioteca mod_python no ha tenido una versión desde 2007 ni un commit desde 2008. La junta directiva de la Fundación Apache votó para eliminar mod_python del conjunto de proyectos activos en sus repositorios de control de versiones, y su desarrollador principal ha desplazado todos sus esfuerzos hacia el backend más ligero, más sutil, más estable y más flexible mod_wsgi.
Si estás utilizando actualmente el manejo de solicitudes mod_python, deberías redepolar tus proyectos Django utilizando otro manejo de solicitudes. mod_wsgi es el recomendado por el proyecto Django, pero FastCGI también está soportado. El soporte para la depuración con mod_python se eliminará en Django 1.5.
Como resultado de la introducción de vistas genéricas basadas en clases, las vistas genéricas basadas en funciones proporcionadas por Django han sido descontinuadas. Los siguientes módulos y las vistas que contienen han sido descontinuados:
django.views.generic.create_update
django.views.generic.date_based
django.views.generic.list_detail
django.views.generic.simple
template atributo¶El cliente de pruebas de Django <test-client> devuelve objetos Response anotados con información extra de prueba. En versiones de Django anteriores a 1.3, esto incluía un atributo template que contenía información sobre las plantillas renderizadas al generar la respuesta: o None, un objeto Template único, o una lista de objetos Template. Esta inconsistencia en los valores de retorno (a veces una lista, a veces no) hacía que el atributo fuera difícil de trabajar.
En Django 1.3 el atributo template está desaconsejado en favor de un nuevo atributo templates que siempre es una lista, incluso si solo tiene un elemento o ninguno.
DjangoTestRunner¶Como resultado de la introducción del soporte para unittest2, las características de django.test.simple.DjangoTestRunner (incluyendo el corte rápido y la terminación de pruebas con Ctrl-C) han sido hechas redundantes. Considerando esta redundancia, DjangoTestRunner ha sido convertido en una clase vacía de lugar holder y será eliminado por completo en Django 1.5.
url y ssi¶La mayoría de las etiquetas de plantilla permiten pasar constantes o variables como argumentos – por ejemplo:
{% extends "base.html" %}
permite especificar una plantilla base como constante, pero si tienes una variable de contexto templ que contiene el valor base.html:
{% extends templ %}
is también legal.
Sin embargo, debido a un accidente de la historia, los url y ssi son diferentes. Estas etiquetas utilizan la segunda sintaxis sin comillas, pero interpretan el argumento como una constante. Esto significa que no es posible utilizar una variable de contexto como objetivo de una etiqueta url y ssi.
Django 1.3 marca el inicio del proceso para corregir este accidente histórico. Django 1.3 agrega una nueva biblioteca de plantillas – future – que proporciona implementaciones alternativas de las etiquetas de plantilla url y ssi. Esta biblioteca future implementa un comportamiento que hace que el manejo del primer argumento sea consistente con el manejo de todas las otras variables. Por lo tanto, una plantilla existente que contenga:
{% url sample %}
debe ser reemplazada con:
{% load url from future %}
{% url 'sample' %}
Las etiquetas que implementan el antiguo comportamiento han sido deprecadas y en Django 1.5, el antiguo comportamiento será reemplazado por el nuevo comportamiento. Para asegurar la compatibilidad con versiones futuras de Django, las plantillas existentes deben ser modificadas para utilizar las nuevas bibliotecas future y sintaxis.
En versiones anteriores, el paquete admin definía los métodos de inicio en múltiples ubicaciones e ignoraba la implementación casi idéntica en el ya utilizado paquete auth. Un efecto secundario de esta duplicidad fue la falta de adopción de los cambios realizados en r12634 para apoyar un conjunto más amplio de caracteres para nombres de usuario.
Esta versión refactoriza el mecanismo de inicio del administrador para utilizar una subclase de la AuthenticationForm en lugar de una validación manual de formularios. El método previamente no documentado 'django.contrib.admin.sites.AdminSite.display_login_form' ha sido eliminado a favor de un nuevo atributo login_form.
reset y sqlreset¶Estos comandos han sido deprecados. Los comandos flush y sqlflush pueden utilizarse para eliminar todo. También puedes utilizar sentencias ALTER TABLE o DROP TABLE manualmente.
La traducción de los textos es la siguiente:
Anteriormente, llamar a transform() no hacía nada de forma silenciosa cuando GDAL no estaba disponible. Ahora, se levanta correctamente un GEOSException para indicar posible código de aplicación defectuoso. Se levanta una advertencia si transform() se llama cuando el SRID de la geometría es menor que 0 o None.
CZBirthNumberField.clean¶Anteriormente, este campo aceptaba en su método clean() un segundo argumento, género, que permitía realizar comprobaciones de validación más estrictas. Sin embargo, como este argumento nunca podía ser pasado desde la maquinaria de formularios de Django, ahora está pendiente de descontinuación.
Esta versión de Django inicia el proceso de descontinuación para la inclusión de traducciones ubicadas bajo el llamado path del proyecto en el proceso de construcción de traducciones realizado en tiempo de ejecución. La configuración CAMINOS DE LOCALE se puede utilizar para el mismo fin agregando al valor de esa configuración el camino de sistema a un directorio locale que contenga traducciones a nivel de proyecto.
Razonamiento detrás de esta decisión:
El path del proyecto siempre ha sido un concepto poco definido (de hecho, el directorio utilizado para localizar las traducciones a nivel de proyecto es el directorio que contiene el módulo de configuración) y se ha producido un cambio en otras partes del marco para dejar de utilizarlo como referencia para la ubicación de activos en tiempo de ejecución.
La traducción de los textos es la siguiente:
Hay problemas potenciales en desarrollo y tiempo de despliegue como el hecho de que el subdirectorio project_dir/locale/ puede generar mensajes de error espurios cuando se agrega el directorio del proyecto a la ruta de Python (manage.py runserver lo hace) y luego choca con el módulo de biblioteca estándar igualmente nombrado, este es un mensaje de advertencia típico:
/usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
import locale, copy, os, re, struct, sys
Esta ubicación no fue incluida en el proceso de construcción de traducciones para literales de JavaScript. Esta deprecación elimina tal inconsistencia.
PermWrapper se ha movido a django.contrib.auth.context_processors¶En Django 1.2, comenzamos el proceso de cambiar la ubicación del procesador de contexto de autenticación desde django.core.context_processors a django.contrib.auth.context_processors. Sin embargo, la clase de soporte PermWrapper se omitió equivocadamente en esa migración. En Django 1.3, también se ha movido la clase PermWrapper a django.contrib.auth.context_processors, junto con la clase de soporte PermLookupDict. Las nuevas clases son funcionalmente idénticas a sus versiones anteriores; solo la ubicación del módulo ha cambiado.
XMLField¶Cuando Django se lanzó por primera vez, Django incluía un campo XMLField que realizaba una validación automática de XML para cualquier entrada de campo. Sin embargo, esta función de validación no ha sido ejecutada desde la introducción de newforms, antes de la versión 1.0. Como resultado, XMLField tal como se implementa actualmente es funcionalmente indistinguible de un simple TextField.
Por esta razón, Django 1.3 ha acelerado la deprecación de XMLField – en lugar de una deprecación de dos versiones, XMLField se eliminará por completo en Django 1.4.
Es fácil actualizar su código para adaptarse a este cambio – simplemente reemplaza todas las referencias a XMLField con TextField, y elimina la argumento de palabra clave schema_path (si está especificado).
may 31, 2026