Bienvenido a Django 0.96!
El objetivo principal para 0.96 es una limpieza y estabilización de las características introducidas en 0.95. Han habido algunas pequeñas cambios incompatibles con la versión anterior desde 0.95, pero el proceso de actualización debería ser bastante simple y no requerir cambios importantes a las aplicaciones existentes.
Sin embargo, también estamos liberando 0.96 ahora porque tenemos un conjunto de cambios incompatibles con la versión anterior programados para el futuro cercano. Una vez completado, implicarán algunos cambios en el código para los desarrolladores de aplicaciones, por lo que recomendamos que mantengas Django 0.96 hasta la próxima liberación oficial; entonces podrás actualizar en un solo paso en lugar de necesitar hacer cambios incrementales para mantenerse al día con la versión de desarrollo de Django.
Los siguientes cambios pueden requerir que actualices tu código cuando cambies de 0.95 a 0.96:
MySQLdb¶Debido a un bug en versiones antiguas del módulo Python MySQLdb (que Django utiliza para conectarse a bases de datos MySQL), el backend de MySQL de Django ahora requiere la versión 1.2.1p2 o superior de MySQLdb, y lanzará excepciones si intentas usar una versión más antigua.
Si actualmente no puedes actualizar tu copia de MySQLdb para cumplir con este requisito, se ha agregado un backend separado y compatible con la versión anterior, llamado «mysql_old». Para utilizar este backend, cambia el parámetro DATABASE_ENGINE en tu archivo de configuración Django desde esto:
DATABASE_ENGINE = "mysql"
a esto:
DATABASE_ENGINE = "mysql_old"
Sin embargo, fuertemente recomendamos a los usuarios de MySQL que actualicen a una versión más reciente de MySQLdb lo antes posible. El backend «mysql_old» se proporciona solo para facilitar esta transición y se considera obsoleto; aparte de cualquier arreglo necesario de seguridad, no será mantenido activamente y será eliminado en una futura liberación de Django.
También ten en cuenta que algunas características, como la nueva configuración DATABASE_OPTIONS (consultar la documentación de bases de datos <doc:databases documentation </ref/databases> para detalles), solo están disponibles en el backend «mysql» y no se harán disponibles para «mysql_old».
El formato de los nombres de las restricciones que Django genera para referencias a claves foráneas ha cambiado ligeramente. Estos nombres se utilizan generalmente solo cuando no es posible colocar la referencia directamente en la columna afectada, por lo que no siempre están visibles.
El efecto de esta modificación es que ejecutar manage.py reset y comandos similares contra una base de datos existente puede generar SQL con la nueva forma del nombre de la restricción, mientras que la base de datos misma contiene restricciones nombradas en la antigua forma; esto causará que el servidor de la base de datos levante un mensaje de error sobre la modificación de restricciones inexistentes.
Si necesitas trabajar alrededor de esto, hay dos métodos disponibles:
Redirige la salida de manage.py a un archivo y edita el SQL generado para utilizar los nombres de las restricciones correctos antes de ejecutarlo.
Examina el resultado de manage.py sqlall para ver los nombres de las restricciones del estilo nuevo, y utiliza eso como guía para renombrar las restricciones existentes en tu base de datos.
Un par de las opciones para manage.py han cambiado con la adición del soporte de fijaciones:
Hay nuevos comandos dumpdata y loaddata que, como podrías esperar, dumping y carga de datos a/desde la base de datos. Estos comandos pueden operar contra cualquier formato de serialización admitido por Django.
La sqlinitialdata command ha sido renombrado a sqlcustom para enfatizar que loaddata debe usarse para datos (y sqlcustom para otros SQL personalizados – vistas, procedimientos almacenados, etc.).
El comando vestigial install ha sido eliminado. Utilice syncdb.
La API de bases de datos de Django ahora escapa los backslashes dados como parámetros de consulta. Si tienes algún código de la API de bases de datos que coincida con backslashes, y estaba funcionando antes (a pesar de la falta de escapada), tendrás que cambiar tu código para «desescapar» las barras una nivel.
Por ejemplo, esto solía funcionar:
# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\\\")
Lo anterior ahora es incorrecto, y debe ser reescrito como:
# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\")
La configuración ENABLE_PSYCO ya no existe. Si tu archivo de configuraciones incluye ENABLE_PSYCO no tendrá efecto; para utilizar Psyco, recomendamos escribir una clase de middleware para activarlo.
Esta revisión representa más de mil commits de código fuente y más de cuatrocientas correcciones de errores, por lo que no podemos catalogar todos los cambios. Aquí describimos los cambios más notables en esta versión.
django.newforms es la nueva biblioteca de Django para manejar formularios. Es una sustitución de django.forms, el antiguo marco de trabajo de formularios/manipulador/validación. Ambas APIs están disponibles en 0.96, pero en las próximas dos versiones planeamos cambiar completamente al nuevo sistema de formularios y deshabilitar y eliminar el viejo sistema.
Hay tres elementos en esta transición:
Hemos copiado la actual django.forms a django.oldforms. Esto permite que actualices tu código ahora en lugar de esperar al cambio incompatible hacia atrás y apresurarte a arreglar tu código después del hecho. Solo cambia tus declaraciones de importación como se describe aquí:
from django import forms # 0.95-style
from django import oldforms as forms # 0.96-style
La próxima versión oficial de Django moverá la actual django.newforms a django.forms. Esto será un cambio incompatible hacia atrás, y cualquier persona que todavía esté utilizando la versión antigua de django.forms en ese momento necesitará cambiar sus declaraciones de importación como se describe arriba.
La siguiente versión después de esa eliminará completamente django.oldforms.
Aunque la biblioteca newforms continuará evolucionando, está lista para uso en los casos más comunes. Recomendamos que cualquier persona nueva en el manejo de formularios pase por alto el sistema antiguo y comience con el nuevo.
Para obtener más información sobre django.newforms, lee la documentación de newforms.
Ahora puedes utilizar cualquier función llamable como callback en los URLconfs (antes, solo se permitían cadenas que se referían a funciones llamables). Esto permite un uso mucho más natural de los URLconfs. Por ejemplo, este URLconf:
from django.conf.urls.defaults import *
urlpatterns = patterns("", ("^myview/$", "mysite.myapp.views.myview"))
Ahora se puede reescribir como:
from django.conf.urls.defaults import *
from mysite.myapp.views import myview
urlpatterns = patterns("", ("^myview/$", myview))
Una aplicación útil de esto se puede ver cuando se utilizan decoradores; esta modificación permite aplicar decoradores a vistas en tu archivo url. De este modo, puedes hacer que una vista genérica requiera inicio de sesión muy fácilmente:
from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_list
from mysite.myapp.models import MyModel
info = {
"queryset": MyModel.objects.all(),
}
urlpatterns = patterns("", ("^myview/$", login_required(object_list), info))
Tenga en cuenta que tanto las sintaxis (cadenas y llamables) son válidas, y seguirán siendo válidas durante el futuro previsible.
Django ahora incluye un marco de prueba para que puedas transformar la inquietud en aburrimiento (con disculpas a Kent Beck). Puedes escribir pruebas basadas en doctest o unittest y probar tus vistas con un cliente de prueba simple.
También hay nuevo soporte para «fijaciones» – datos iniciales, almacenados en cualquier de los formatos de serialización admitidos </topics/serialization>, que se cargarán en tu base de datos al comienzo de tus pruebas. Esto hace que probar con datos reales sea mucho más fácil.
Consulte la documentación de prueba para obtener los detalles completos.
Un pequeño cambio, pero muy agradable: se han agregado vistas dedicadas para agregar y actualizar usuarios a la interfaz administrativa, por lo que ya no necesitas preocuparte por trabajar con contraseñas hashadas en el admin.
Desde la versión 0.95, un número de personas han avanzado y asumido un nuevo papel importante en el desarrollo de Django. Les gustaría agradecer a estas personas por todo su trabajo duro:
Russell Keith-Magee y Malcolm Tredinnick por sus contribuciones importantes al código. Esta versión no habría sido posible sin ellos.
Nuestro nuevo gerente de lanzamientos, James Bennett, por su trabajo en sacar 0.95.1, 0.96 y (esperamos) futuras versiones.
Nuestros administradores de tickets Chris Beaven (aka SmileyChris), Simon Greenhill, Michael Radziej y Gary Wilson. Acordaron asumir la monumental tarea de gestionar nuestros tickets para catalogarlos en una presentación ordenada. Ahora saber qué trabajar es sobre un millón de veces más fácil; gracias otra vez, chicos.
A todos los que enviaron un informe de bug, parche o comentario de ticket. No podemos agradecer a todos por nombre – más de 200 desarrolladores enviaron parches que se incluyeron en la versión 0.96 – pero todos los que han contribuido con Django están listados en AUTHORS.
may 31, 2026