Bienvenidos a Django 1.0!
Hemos estado esperando este momento durante más de tres años, y finalmente está aquí. Django 1.0 representa el mayor hito en el desarrollo de Django hasta la fecha: un marco web que un grupo de perfeccionistas puede estar verdaderamente orgulloso.
Django 1.0 representa más de tres años de desarrollo comunitario como proyecto Open Source. Django ha recibido contribuciones de cientos de desarrolladores, ha sido traducido a cincuenta idiomas y hoy es utilizado por desarrolladores en cada continente y en todos los tipos de trabajo.
Nota histórica interesante: cuando Django se lanzó por primera vez en julio de 2005, la versión inicial lanzada de Django vino desde un repositorio interno con el número de revisión 8825. Django 1.0 representa la revisión 8961 de nuestro repositorio público. Parece adecuado que nuestro lanzamiento 1.0 llegue en el momento donde las contribuciones comunitarias superan aquellas hechas privadamente.
La liberación de Django 1.0 viene acompañada por la promesa de estabilidad de la API y compatibilidad hacia adelante. En resumen, esto significa que el código que desarrollas contra Django 1.0 continuará funcionando sin cambios en 1.1, y solo necesitarás realizar cambios menores para cualquier liberación 1.X.
Consulte la guía de estabilidad de la API <misc/api-stability> para obtener detalles completos.
Django 1.0 tiene un número de cambios incompatibles con Django 0.96. Si tienes aplicaciones escritas contra Django 0.96 que necesitas portar, consulta nuestra guía de portación detallada:
Puedes encontrar una lista completa de los cambios incompatibles hacia atrás en https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
¡Muchas!
Desde Django 0.96, hemos realizado más de 4,000 commits de código, corregido más de 2,000 bugs y editado, agregado o eliminado alrededor de 350,000 líneas de código. También hemos agregado 40,000 líneas de documentación nueva y mejorado significativamente lo que ya estaba allí.
De hecho, la documentación nueva es una de nuestras características favoritas de Django 1.0, así que empezaremos por ahí. Primero, hay un nuevo sitio web de documentación:
La documentación ha sido mejorada enormemente, limpiada y generalmente hecha genial. Ahora hay búsqueda dedicada, índices y más.
No podemos documentar todo lo nuevo en 1.0, pero la documentación será tu guía definitiva. En cualquier lugar donde veas algo como:
Esta característica es nueva en Django 1.0
Sabrás que estás mirando algo nuevo o cambiado.
Los otros destacados principales de Django 1.0 son:
La interfaz administrativa de Django (django.contrib.admin) ha sido refactoreada completamente; las definiciones de administrador están ahora completamente desacopladas de las definiciones de modelo (¡no hay más declaración de class Admin en modelos!), reescritas para utilizar la biblioteca de manejo de formularios de Django (introducida en la versión 0.96 como django.newforms, y ahora disponible simplemente como django.forms) y rediseñadas con extensibilidad y personalización en mente. La documentación completa de la aplicación administrativa está disponible en línea en la documentación oficial de Django:
Consulta la referencia del administrador <doc>`admin reference </ref/contrib/admin/index>` para detalles
Los internos de Django han sido refactoreados para utilizar Unicode en todo momento; esto simplifica enormemente la tarea de tratar con contenido y datos no occidentales europeos en Django. Además, se han proporcionado funciones de utilidad para facilitar la interoperabilidad con bibliotecas y sistemas terceros que pueden o no manejar Unicode con gracia. Los detalles están disponibles en la documentación del manejo de Unicode de Django.
See Datos Unicode.
La mapeadora objeto-relacional de Django – el componente que proporciona la correspondencia entre las clases de modelo de Django y su base de datos, y que media sus consultas a la base de datos – ha sido drásticamente mejorada por una refactorización masiva. Para la mayoría de los usuarios de Django esto es compatible hacia atrás; la API pública para consultar la base de datos sufrió unos pocos cambios menores, pero la mayoría de las actualizaciones tuvieron lugar en los internos del ORM. Una guía a los cambios, incluyendo modificaciones incompatibles con el pasado y menciones de nuevas características abiertas por esta refactorización, está disponible en el wiki de Django.
Para proporcionar una seguridad mejorada contra vulnerabilidades de scripting entre sitios (XSS), ahora el sistema de plantillas de Django escapa automáticamente la salida de las variables. Este comportamiento es configurable, y permite que tanto las variables como los constructos de plantilla más grandes estén marcados como seguros (requieren no escapar) o inseguros (requieren escapar). Una guía completa a esta característica está en la documentación del autoescape etiqueta.
django.contrib.gis (GeoDjango)¶Un proyecto que lleva más de un año en elaborarse, esto agrega soporte de clase mundial para sistemas de información geográfica (Geographic Information Systems) a Django, en forma de una aplicación contrib. Su documentación se está manteniendo actualmente externamente y será fusionada con la documentación principal de Django pronto. Un enorme agradecimiento va a Justin Bronn, Jeremy Dunck, Brett Hoerner y Travis Pinney por sus esfuerzos en crear y completar esta característica.
Ver GeoDjango para detalles.
Ahora los campos FileField y ImageField integrados en Django pueden aprovechar los backends de almacenamiento de archivos personalizables, lo que permite una personalización extensa de dónde y cómo se almacenan los archivos subidos por Django. Para detalles, ver la documentación sobre archivos; un enorme agradecimiento va a Marty Alchin por poner el trabajo duro para completar esto.
Gracias al trabajo de Leo Soto durante un proyecto del Google Summer of Code, el código base de Django ha sido refactorizado para eliminar las incompatibilidades con Jython, una implementación de Python escrita en Java que ejecuta código Python en la Máquina Virtual de Java. Django es compatible ahora con la próxima versión de Jython 2.5.
Las clases están incluidas en django.contrib.contenttypes que se pueden utilizar para apoyar relaciones genéricas tanto en la interfaz de administración como en los formularios de usuario final. Consulte la documentación sobre relaciones genéricas para obtener más detalles.
INSERT y UPDATE¶Aunque el comportamiento predeterminado de Django de que el método save() de un modelo determine automáticamente si realizar una operación INSERT o UPDATE a nivel SQL es adecuado para la mayoría de los casos, hay ocasiones en las que forzar uno u otro puede ser útil. Como resultado, los modelos pueden ahora admitir un parámetro adicional al método save() que pueda forzar una operación específica.
Consulte Forzando un INSERT o UPDATE para obtener más detalles.
CacheMiddleware¶La clase de middleware CacheMiddleware de Django ha sido dividida en tres clases: CacheMiddleware sigue existiendo y mantiene todas sus funciones previas, pero ahora está construida a partir de dos clases de middleware separadas que manejan las dos partes del caché (insertar en el caché y leer del caché) por separado, ofreciendo flexibilidad adicional para situaciones donde combinar estas funciones en una sola clase de middleware planteaba problemas.
Detalles completos, incluyendo notas actualizadas sobre su uso adecuado, se encuentran en la documentación sobre caché.
Como parte de un proyecto del Google Summer of Code, Thejaswi Puthraya llevó a cabo una importante reescritura y refactorización del sistema de comentarios integrado en Django, lo que aumentó significativamente su flexibilidad y personalizabilidad.
Un número de características y métodos que habían sido marcados como obsoletos y que estaban programados para ser eliminados antes de la versión 1.0, ya no están presentes en Django. Estos incluyen importaciones de la biblioteca de formularios desde django.newforms (ahora ubicada simplemente en django.forms), las funciones auxiliares form_for_model y form_for_instance (que han sido reemplazadas por ModelForm) y un número de características obsoletas que fueron reemplazadas por la refactorización del dispatcher, subida de archivos y almacenamiento de archivos introducidas en las versiones alpha 1.0 de Django.
Hemos hecho nuestro mejor esfuerzo para hacer que Django 1.0 sea lo más sólido posible, pero desafortunadamente hay un par de problemas que sabemos sobre la versión.
to_field¶Si estás utilizando herencia de modelos con múltiples tablas, ten en cuenta esta advertencia: los modelos hijos que utilizan un parent_link y to_field personalizados causarán errores de integridad de la base de datos. Un conjunto de modelos como el siguiente son no válidos:
class Parent(models.Model):
name = models.CharField(max_length=10)
other_value = models.IntegerField(unique=True)
class Child(Parent):
father = models.OneToOneField(
Parent, primary_key=True, to_field="other_value", parent_link=True
)
value = models.IntegerField()
Este problema se solucionará en la próxima versión de Django.
Django intenta apoyar tantas características como sea posible en todos los backends de bases de datos. Sin embargo, no todos los backends de bases de datos son iguales, y en particular muchas de las bases de datos admitidas difieren mucho de versión a versión. Es una buena idea consultar nuestras notas sobre bases de datos admitidas:
may 31, 2026