Not one but two expedited releases! 🎉 🎉 https://www.python.org/downloads/release/python-3140rc2/ The ABI isn’t changing. Wheels built for rc1 should be fine for rc2, rc3 and 3.14.x. So this shouldn’t affect too many people but let’s get this out for testing sooner. Due to this early release, we’ll also add a third release candidate between now and the final 3.14.0 release, with no planned change to the final release date. This release, , is the penultimate release preview. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The next pre-release of Python 3.14 will be the final release candidate, 3.14.0rc3, scheduled for 2025-09-16; the official release of 3.14.0 is scheduled for Tuesday, 2025-10-07. There will be from this point forward in the 3.14 series, and the goal is that there will be as few code changes as possible. We maintainers of third-party Python projects to prepare their projects for 3.14 during this phase, and publish Python 3.14 wheels on PyPI to be ready for the final release of 3.14.0, and to help other projects do their own testing. Any binary wheels built against Python 3.14.0 release candidates with future versions of Python 3.14. As always, report any issues to . the Python bug tracker Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is recommended for production environments. Some of the major new features and changes in Python 3.14 are: For more details on the changes to Python 3.14, see . What’s new in Python 3.14 The installer we offer for Windows is being replaced by our new install manager, which can be installed from or from its . See for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. the Windows Store download page our documentation https://www.python.org/downloads/release/python-3137/ Python 3.13 is the newest major release of the Python programming language, and it contains many new features and optimizations compared to Python 3.12. 3.13.7 is the seventh maintenance release of 3.13. 3.13.7 is an expedited release to fix a significant issue with the 3.13.6 release: A few other bug fixes (which would otherwise have waited until the next release) are also included. The magpie, in Latin, is a black and white bird in the crow family, known for its chattering call. The first-known use in English is from a , where magpie is spelled “magpy” and cuckoo is “cookow”: 1589 poem The name comes from Mag, short for Margery or Margaret (compare robin redbreast, jenny wren, and its corvid relative jackdaw); and pie, a magpie or other bird with black and white (or pied) plumage. The sea-pie (1552) is the oystercatcher, the grey pie (1678) and murdering pie (1688) is the great grey shrike. Others birds include the yellow and black pie, red-billed pie, wandering tree-pie, and river pie. The rain-pie, wood-pie and French pie are woodpeckers. Pie on its own dates to before 1225, and comes from the Latin name for the bird, . Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from a busy Helsinki on , Night of the Arts Your release team, Hugo van Kemenade Thomas Wouters Ned Deily Steve Dower Å�ukasz Langa

The latest version of Python 3.13 is now available! Python 3.13 is the newest major release of the Python programming language, and it contains many new features and optimizations compared to Python 3.12. 3.13.6 is the sixth maintenance release of 3.13, containing around 200 bugfixes, build improvements and documentation changes since 3.13.5. Full Changelog Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation, . especially now Regards from your package managers,

the first 3.14 release candidate! It’s https://www.python.org/downloads/release/python-3140rc1/ This release, , is the penultimate release preview. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The second candidate (and the last planned release preview) is scheduled for Tuesday, 2025-08-26, while the official release of 3.14.0 is scheduled for Tuesday, 2025-10-07. There will be from this point forward in the 3.14 series, and the goal is that there will be as few code changes as possible. We maintainers of third-party Python projects to prepare their projects for 3.14 during this phase, and where necessary publish Python 3.14 wheels on PyPI to be ready for the final release of 3.14.0, and to help other projects do their own testing. Any binary wheels built against Python 3.14.0rc1 with future versions of Python 3.14. As always, report any issues to . the Python bug tracker Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is recommended for production environments. Some of the major new features and changes in Python 3.14 are: For more details on the changes to Python 3.14, see . The next pre-release of Python 3.14 will be the final release candidate, 3.14.0rc2, scheduled for 2025-08-26. What’s new in Python 3.14 The installer we offer for Windows is being replaced by our new install manager, which can be installed from or from its . See for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. the Windows Store download page our documentation Today, 22nd July, is Pi Approximation Day, because 22/7 is a common approximation of and closer to than 3.14. 22/7 is a Diophantine approximation, named after Diophantus of Alexandria (3rd century CE), which is a way of estimating a real number as a ratio of two integers. 22/7 has been known since antiquity; Archimedes (3rd century BCE) wrote the first known proof that 22/7 overestimates by comparing 96-sided polygons to the circle it circumscribes. Another approximation is 355/113. In Chinese mathematics, 22/7 and 355/113 are respectively known as Yuelü (约率; yuÄ“lÇœ; “approximate ratio”) and Milü (密率; mìlÇœ; “close ratio”). Happy ! Pi Approximation Day Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from a Helsinki heatwave after an excellent , EuroPython Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

the final 3.14 beta! It’s https://www.python.org/downloads/release/python-3140b4/ Python 3.14 is still in development. This release, 3.14.0b4, is the last of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We maintainers of third-party Python projects to during the beta phase and report issues found to as soon as possible. While the release is planned to be feature-complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2025-07-22). Our goal is to have after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be to get as much exposure for 3.14 as possible during the beta phase. the Python bug tracker This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. Please keep in mind that this is a preview release and its use is recommended for production environments. Some of the major new features and changes in Python 3.14 are: For more details on the changes to Python 3.14, see . The next pre-release of Python 3.14 will be the first release candidate, 3.14.0rc1, scheduled for 2025-07-22. What’s new in Python 3.14 The installer we offer for Windows is being replaced by our new install manager, which can be installed from or from its . See for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. the Windows Store download page our documentation All this talk of and yet some say is wrong. (June 28th, 6/28 in the US) celebrates as the “true circle constant”, as the ratio of a circle’s circumference to its radius, = 6.283185… The declares “a confusing and unnatural choice for the circle constant”, in part because “ occurs with astonishing frequency throughout mathematics”. Tau Day Tau Manifesto If you wish to embrace the good news is added to Python 3.6 in 2016: PEP 628 math.tau When working with radians, it is trivial to convert any given fraction of a circle to a value in radians in terms of . A quarter circle is , a half circle is , seven 25ths is , etc. In contrast with the equivalent expressions in terms of (, , ), the unnecessary and needlessly confusing multiplication by two is gone. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from a cloudy Helsinki, looking forward to Prague and next week, EuroPython Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

It’s 3.14 beta 3! https://www.python.org/downloads/release/python-3140b3/ Python 3.14 is still in development. This release, 3.14.0b3, is the third of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We maintainers of third-party Python projects to during the beta phase and report issues found to as soon as possible. While the release is planned to be feature-complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2025-07-22). Our goal is to have after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be to get as much exposure for 3.14 as possible during the beta phase. the Python bug tracker This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. Please keep in mind that this is a preview release and its use is recommended for production environments. Some of the major new features and changes in Python 3.14 are: For more details on the changes to Python 3.14, see . The next pre-release of Python 3.14 will be the final beta, 3.14.0b4, scheduled for 2025-07-08. What’s new in Python 3.14 The installer we offer for Windows is being replaced by our new install manager, which can be installed from or . See for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. the Windows Store our FTP page our documentation If you’re heading out to sea, remember the : Maritime Approximation mph = knots Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from sunny Helsinki with 19 hours of daylight, Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

When I was younger we would call this a brown paper bag release, but actually, we shouldn’t hide from our mistakes. We’re only human. So, please enjoy: Python 3.13 is the newest major release of the Python programming language, and it contains many new features and optimizations compared to Python 3.12. 3.13.5 is the fifth maintenance release of 3.13. 3.13.5 is an expedited release to fix a couple of significant issues with the 3.13.4 release: Several other bug fixes (which would otherwise have waited until the next release) are also included. Special thanks to everyone who worked hard the last couple of days to fix these issues as quickly as possible. Full Changelog As always, upgrading is highly recommended to all users of 3.13. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from hey, it’s us again, your release team, Thomas Wouters Ned Deily Steve Dower Å�ukasz Langa

It was only meant to be release day for 3.13.4 today, but poor number 13 looked so lonely… And hey, we had a couple of tarfile CVEs that we had to fix. So most of the Release Managers and all the Developers-in-Residence (including Security Developer-in-Residence Seth Michael Larson) came together to make it a full release party. In addition to the security fixed mentioned above, a few additional changes to the were backported to make the security fixes feasible. (See the full changelogs for each release for more details.) In addition to the security fixes, the fourth maintenance release of Python 3.13 contains more than 300 bugfixes, build improvements and documentation changes. https://www.python.org/downloads/release/python-3134/ https://www.python.org/downloads/release/python-31211/ https://www.python.org/downloads/release/python-31113/ Additional security content in this release (already fixed in older releases for the other versions): As always, upgrading is highly recommended to all users of affected versions. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from your very tireless release team, Thomas Wouters Pablo Galindo Salgado Å�ukasz Langa Ned Deily Steve Dower

tl;dr A summary of resources and learnings related to building REST API I put together over the last couple of years. Complete API development workflow from Django backend to frontend clients using Django REST Framework, drf-spectacular for OpenAPI spec generation, and automated client generation with openapi-generator. Big productivity boost! There is a lot of discussion about frameworks for building REST APIs, some of them being even able to generate OpenAPI specs directly for you. Django is not quite known for that, but there are ways of doing this by automating most of the process while being very productive and offering your team a clean developer experience. Overview The stack I prefer makes use of several additional modules you will require: django-rest-framework and drf-spectacular alongside Django. REST Framework helps you extend your application in order to have a REST API, while drf-spectacular will help you the ability to generate the OpenAPI spec (standalone post: Create OpenAPI spec for Django REST Framework APIs. After having the OpenAPI spec, you can generate clients with openapi-generator. Here is an example I mapped out of generating an Angular client: Step-by-step process There is also a recording from my GLT 2025 talk where I summarize most of these ideas. Building Better APIs - From Django to Client Libraries with OpenAPI In case you want to follow along, here is a step-by-step guide from the repository I showed during the presentation: Create a Django project Add a Django app Models and database migrations DRF serializers DRF views Configure URLs Add and configure drf spectacular Generate OpenAPI From the last step, you can generate the API clients for the platform you require. You can follow the README and the examples available in my glt25-client repository. Maintaining compatibility over time The final tool you can use is openapi-diff, which will help you keep your documentation compatible. This is very important once your REST API is used in production: Example of a compatible change: glt25-demo v1 to v2 docker run --rm -t openapitools/openapi-diff:latest https://github.com/nezhar/glt25-demo/releases/download/v1/openapi.yaml https://github.com/nezhar/glt25-demo/releases/download/v2/openapi.yaml Example of a breaking change: glt25-demo v2 to v3 docker run --rm -t openapitools/openapi-diff:latest https://github.com/nezhar/glt25-demo/releases/download/v2/openapi.yaml https://github.com/nezhar/glt25-demo/releases/download/v3/openapi.yaml Automating the maintenance The process can be automated even further using GitHub Actions and Dependabot. Here are what the steps look like with this full continuous delivery setup: Takeways Building a complete API development workflow from Django to client libraries using OpenAPI creates a powerful and maintainable development experience. By combining Django REST Framework with drf-spectacular for automatic OpenAPI spec generation and openapi-generator for client creation, you can eliminate manual API documentation and reduce integration errors. If you want to go even further, you can automate the integration of error codes inside the OpenAPI spec. This way you can better support languages that are even more strict when consuming the REST API! Thank you to Harald Nezbeda for proposing this guest post on the Django blog!

We are pleased to welcome Jacob Tyler Walls as the newest member of the Django Fellowship team. Jacob joins Natalia Bidart and Sarah Boyce, who continue in their roles as Django Fellows. Jacob is a full-stack developer and open-source maintainer with five years of experience using and contributing to Django. He got involved in open source thanks to music technology. After majoring in music and philosophy at Williams College, Jacob earned a Ph.D. in music composition from the University of Pennsylvania. Programming coursework both fed into his creative output and also led to roles as a Python generalist working on music information retrieval and as a developer for an interactive music theory instruction site using Django. As a member of Django’s Triage & Review Team, Jacob is passionate about software testing and eager to pay forward the mentorship he received as a contributor. Jacob also co-maintains the Python projects music21 and pylint. Most recently, as part of his work as a core developer of Arches, an open-source Django/Vue framework for managing cultural heritage data, Jacob had the opportunity to explore the expressive potential of Django’s ORM. He gave a DjangoCon talk on his experience adapting QuerySets to work with highly generic data access patterns and an analogous talk for an audience of Arches developers. Since 2022, he has focused on developing GIS-powered Django apps at Azavea and later Farallon Geographics. When time permits, Jacob continues to teach music theory, including most recently as an adjunct faculty member at the University of Delaware. (Perhaps another time Django Reinhardt will end up on the syllabus.) You can find Jacob on GitHub as @jacobtylerwalls and follow occasional musical updates at jacobtylerwalls.com Thank you to all the applicants to the Fellowship. We hope to expand the program in the future, and knowing there are so many excellent candidates gives us great confidence as we work toward that goal.

The Django accessibility team is excited to announce that our accessibility contribution guidelines are now live in the documentation 🎉 These new guidelines are designed to support contributors in making Django more accessible to all users — including those who navigate the web using screen readers, keyboard-only inputs, and other assistive technologies. They outline practical steps for designing and testing accessible user interfaces, how to contribute, follow up on ongoing accessibility issues, and contact the team. For beginners, we also recommend resources like The A11Y Project to get started. We welcome your feedback and contributions as we continue to improve accessibility across the Django ecosystem! Come say hi on the Django Forum: Accessibility contributing guide.

Today we've issued the 5.2.5 bugfix release. The release package and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is : 3955B19851EA96EF

For July 2025, we welcome Jake Howard as our DSF member of the month! ⭐ Jake actively shares his knowledge through blog posts and community talks. He is part of the Security Team Working Group and he created the DEP 14. He has been a DSF member since June 2024. You can learn more about Jake by visiting Jake's website and his GitHub Profile. Let’s spend some time getting to know Jake better! Can you tell us a little about yourself (hobbies, education, etc) I’m Jake. I’m a Senior Systems Engineer at Torchbox, where I’ve been for a little over 4 years. “Systems Engineer” is a fairly loaded title, and means different things to different people. I like to describe it as doing everything technical to do with Software Engineering which isn’t Programming (Sysadmin, Devops, IT support, Security, Networking), but also doing a fair bit of Programming. Most of my hobbies revolve around technology. I’m an avid self-hoster, running applications on servers both in “the cloud” and in my house. There’s been a server of some kind in my house for the last 10 years. I’m generally quite a private person, so I like to know what’s happening to my data. Since I started working remotely at the start of the 2020 pandemic, I’ve channeled some of this passion into posts on my website, with posts about all manner of things I’ve done from self-hosting to general software engineering. Away from my desk (sort of), I’m a volunteer for Student Robotics, inspiring college students into STEM through competitive robotics (no, not quite like Robot Wars). In school, I was always the quiet one, but now I seem completely at home with public speaking, commentary and otherwise being in front of large crowds of people. I wish I knew the secret - I’d make millions! My GitHub is also pretty active, with contributions all over the place (OpenZFS, Nebula VPN, Gitea, Plausible Analytics, OpenCV, Ansible…). I’m curious, where your nickname “RealOrangeOne” comes from? Because a lot of life happens online (especially in the last 5 years), many people haven’t even seen pictures of me, let alone met me in person. I am not in fact a talking piece of fruit. For a while, I tried to stay anonymous, avoiding photos or videos of me on the internet. But since I discovered I enjoy public speaking, I’ve sort of given up on that (for the most part). By now, I’m sure many people have speak. But, for those who don’t know: I, like my father before me, am ginger 🔥 (the hair colour, not the plant). The exact specifics of how being ginger lead to “TheOrangeOne” are sadly lost to time. I’ve owned theorangeone.net for well over a decade at this point. Unfortunately, it’s not a particularly original nickname, and I have to be fast to claim it when signing up to new services. In some places (where I wasn’t fast enough) I’m forced to sub out “The” for “Real”, which has lead to some confusions, but not too many. Canonically, I prefer “TheOrangeOne”, but as we all know, naming things is hard. How did you start using Django? I’ve been using Django since around the 1.8 release. My job at the time was at a Django development agency, so it was the first real Python framework I’d used. The first few weeks there was my first exposure to Django, pip, package management and collaborative software engineering - it was quite a lot to learn at once. I didn’t realise it at the time, but I was working working as a junior alongside a couple fairly well-known names in the Django community like Tom Christie (DRF, Starlette, HTTPX) and Jamie Matthews (django-readers, django-zen-queries). We mostly built single-page apps with React, so I learned Django and Django Rest Framework at the same time, which means I now often have to look back at the docs to remember how forms and templates work. As for contributing to Django, that came much later. My first commit to Django was in May 2024. Having used Django for a while, and written plenty of packages, I’d never stopped to look at how upstream was developed. Around the time of DEP 14 kicking off, I needed to look a bit more at the inner workings of the Django project, to learn what was in store for me. When scrolling through Trac tickets, I found an interesting looking ticket, and got to work. At the time of writing, I’ve now closed 9 Trac tickets across 12 PRs, and some pretty cool features (simple block tags, better Accept header parsing, performance improvements to the URL router) now have my name on them (metaphorically speaking). I wouldn’t call myself an “active” contributor, but I try and keep an eye on the tickets and forum threads which interest me the most, and chime in when I can. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? Since it’s the first framework I learned, and so far has done everything I need, I’ve mostly used Django. For a few smaller services, I’ve leaned more towards Starlette and AIOHTTP, but for anything even slightly large I’ve just used Django - since I’d end up recreating much of Django using the smaller frameworks anyway. A better (likely official) path for single-file Django (ie without some of the magic module handling) might help draw a few more people in and fill a few more of these “micro-service” style use-cases. I’m a class-based views person - I like the encapsulation and easy extension of base views. As with any opinion on the internet, I’m sure many people disagree with me, but to me it’s just personal preference. I’m still surprised it’s a pattern not seen by many other Python frameworks. Following in the footsteps of Python, I often wonder if Django could also do with some dead battery removal (or at least extracting into separate packages). Django is a pretty big framework, and whilst the contrib apps are intended to be separate, they also require hooks and assumptions in other areas of the codebase. I might be wrong (it happens quite a lot), but I suspect some of those packages would be better suited externally, perhaps improving some developer momentum - and lightening the load for the Fellows. Django’s sitemap and syndication (RSS) frameworks are 2 places I wish would get some more love. Outside of Python, I’m a big fan of Rust (as cliche as it may be). Whilst Rust is a popular language, there isn’t really a “Django” like (batteries included) framework - it’s all composing the pieces you need yourself. However, that doesn’t stop people being very productive with it. As a result, most of the frameworks have very generic interfaces, letting developers pass state around as needed, rather than trying to do everything themselves. Outside of the obvious static typing debate (which I’m in favour of), I’d love to see Django embrace some dependencies, especially if they bring some performance improvements. It may end up being a bad idea, but it might also help those who want to use Django’s modules outside of Django. Many years ago, I tried to be a polyglot - switching between different programming languages (and frameworks) to find new ways of working and match the problem to the correct solution. Now, I’ve settled mostly on Python and Rust. They fit my needs well, I’m very productive in them, and between the 2 there’s not much they can’t handle. Given my background, and the fact most sysadmin-y tools are written in it, I’m really not a fan of Go. What projects are you working on now? Over time, I’ve slowly stepped back from having big side projects - being a new dad sure takes up time and energy. Large projects ended up feeling too much like work outside of work, and I end up either getting distracted or bored. After work, I want to do something fun, not that seems like yet another job. I’m the kind of person who gets the sudden urge to research something interesting for an evening, dive in, then not think about it again for several weeks. It’s not the most productive way of doing things, which is why my posts are all over the place, but it doesn’t feel much like work for me - I lean heavily on what interests me at any time to drive what I want to do. With that said, I’m currently in the process of rebuilding my website. Of course, both the current and new versions are built on Django, but the new build should be easier to maintain, faster, and hopefully won’t need rewriting again in just a couple years. Most of my other projects have been small tools to make my home server that bit nicer. Professionally, I’m not really a developer anymore. As a sysadmin (ish), much of my day-to-day doesn’t involve much programming. I spend much more of my time deploying, monitoring and administering Django applications than I do writing them. My main project at the moment is helping port a large Java / JS deployment over to Django and Wagtail, running on Kubernetes with some very high and interesting stability and scaling requirements. Since most of my professional live has been at software agencies, I’ve tended to bounce between different projects, rather than sitting on a single one. So I’m also supporting on a few other smaller projects as and when I’m needed. Which Django libraries are your favorite (core or 3rd party)? django-tasks, of course! … Oh right, a serious answer… I have to say, one of the most underrated modules in Django is django.utils. It’s not as glamourous as the ORM, forms or cache, but it’s a treasure trove of useful methods. I personally always like looking at the internal helper functions large frameworks use - see the problems they’ve had to solve time and time again. Whilst there’s not the same stability guarantees, I’ve definitely been helped out on a few occasions by some undocumented functions. In that theme, I’m a fan of libraries which do one thing and do it well. I quite like small libraries which aim to solve a problem. There’s definitely a line before that becomes a problem (anyone remember left-pad?), but libraries which scope creep are often harder to work with than the more narrow-scoped ones, whilst the smaller ones just keep on working and making my life easier. For example, django-environ makes reading and parsing environment variables into settings really easy and clean, and django-decorator-include helps including other urlpatterns whilst wrapping them in a decorator - particularly helpful for 3rd-party package’s URLs. Finally, I’ve got a real soft-spot for whitenoise (and ServeStatic for ASGI users). Django’s documentation deters people pretty hard from serving media and static files using Django - and rightly so in performance-critical environments. However, for most people, having to additionally maintain (and secure) nginx is more maintenance than necessary. whitenoise serves static files using Django directly, without any extra configuration, whilst also pre-compressing files for a nice performance boost. To me, it’s such a universally-useful library, I’d love to see it it included in Django itself someday. I’ll throw a bonus shout out for granian, a new (ish) WSGI / ASGI server written in Rust. gunicorn has a near monopoly on running Python apps in production, especially in the WSGI space, so it’s nice to see a newcomer. granian isn’t always faster, but doing the HTTP handling in Rust (and using popular libraries to do it) can improve stability and throughput, without holding the GIL. I’ve not run anything in production with it yet, but I’ve been using it on personal projects for almost a year without issue. What are the top three things in Django that you like? Contrary to what I’ve already said, I actually like Django’s batteries. Sure, there’s quite a few “dead” ones in need of some cleaning up and TLC, but having most of what I need already installed makes me far more productive. I don’t need to think about how to render my form on the page, save the results as a model, or properly handle errors - everything “just works”, and works together. Sure, batteries have their downsides - it makes swapping them out rather difficult, but I’d rather ship my feature sooner than compare the trade-offs of different ORMs. The auto-reloading in django-tasks is only around 8 lines of code thanks to django.utils.autoreload being so easy to hook in to. Secondly: Forms, but not for the reasons you might think. Most forms are created to take submissions from the user, validate them, then probably save them to a model. However, they’re great as general data validation. I’ve written plenty of views with complex querystring requirements, and leaning on forms to validate them saves a lot of boilerplate code. Sure, pydantic might be a bit faster and have more features, but given I’m already productive with django.forms, and it’s already installed and well understood by other developers in my team, I don’t feel the need to reach for something else. Finally, I wouldn’t say it’s quite a “favourite”, and it’s well-known as being far-from-perfect, but I’ve got a real soft-spot for the Django Admin. It lets me focus on building the core of an application, rather than the internal interface - particularly when there are no strong requirements for it, or it’s only going to be used by me and a few others. Since it’s a fair raw view of the database by default, I’ve definitely been bitten by some less-than-restrictive permissions, but there’s generally all the hooks I need. I don’t like building frontends, so only needing to build 1 rather than 2 makes me a lot happier, especially if it comes with authentication, permissions, read-only views and a dark mode 😎! How did you join the security team? I’d love to say it’s an interesting story, stroking my ego that I saved the day. But the reality is, as usual, far less glamorous. As an engineer, I’ve tended towards 2 specialties: Security and Performance, which usually go hand-in-hand. In early 2023, I was invited to join the Wagtail CMS Security team after reporting and subsequently helping fix a memory exhaustion issue. I was already involved in all things security at Torchbox, especially our ISO-27001 certification, so I was already known when I submitted a vulnerability report. Thibaud mentioned to me late last year that the project potentially looking for new members of the security team, to help with resourcing and some potential process improvements within the foundation. I naturally jumped at the opportunity - since the team is generally closed to new members and “fully-staffed”. After a few gentle reminders (he’s a busy guy), I received a message from Sarah formally inviting me in March. Since then, I’ve tried to review every report which came through, and helped author a few patches. A few reports even had to be raised upstream with Python’s Security Response Team (PSRT). It’s been an interesting experience, and I’m looking forward to seeing how the team developers over the coming years. I’m aware that you have created DEP 14 on the Background Workers, how the work is going so far? Do you need support from the community on anything? DEP 14 (the proposal to add a native background workers API to Django) has been a really interesting journey. I’m beyond humbled to see the community interest behind it. When I started down this road, I’d only intended to start the conversations and help rally the community interest. Since then, and 6000 lines of code later, I’m mostly single-handedly writing a database-backed production-grade task system. Right now, we’re at a bit of a cross-roads. Many of the foundational parts work, relatively well. The difficulty comes with the more complex features: Retries, dependencies, robust execution. Building a task system is easy - building a reliable one people want to actually use is incredibly difficult. If anyone out there is interested in getting involved, please do! Report issues, fix bugs, contribute to design discussions. Most of the APIs are based on what I think looks sensible. Software this large, pivotal and complex can’t be built in isolation - so it needs a diverse audience to ensure we (I) make the right decisions, and design an API people actually want to use that will last and scale for years to come. The next challenge on my list to tackle is timeouts - a highly requested feature. It sounds simple, but the reality is far from it. Many of those challenges sparked the topic of my upcoming PyCon UK talk later this year. Django is celebrating its 20th anniversary this month. Any nice story to share? My personal highlight was DjangoCon Europe 2024 - my first DjangoCon. I ended up bringing the stereotypically grey British weather with me, but I had a great week chatting Django with some interesting people, and putting faces to the names and handles I’d seen online. After the talk announcing DEP 14 and background tasks, I was inundated with people voicing their support - many wondering how it’d taken this long. But personally, I’m more interested in what’s to come. Of course, there’s django-tasks, but the next sets of releases are shaping up to be pretty interesting. Over the last 3-4 years or so, I’ve personally noticed a bit of a resurgence in people’s appetites for change in Django. The 6.x Steering Council have a lot of interesting ideas, and clearly the community agree. People are happy with what Django can do now, but want to bring it a little more up-to-date - and are happy to put in the work to do it. Only a few weeks ago, django-csp was included in core, making it easier to make more secure applications. I’m sure that’s just the start. The fact people are still keen on working on a framework which just celebrated 20 years shows it must be doing something right! Is there anything else you’d like to say? I’d like to thank whoever nominated me to be a DSF member in the first place. To this date, I have no idea who you are. Beyond that, I’m just looking forward to seeing what comes of Django, and Python in general over the next few years. Thank you for doing the interview, Jake !

Hello Django 🌌 Universe! 🛰️‍ This is Djangonaut Space phoning home about Session 5! We're recruiting technical mentors (Navigators) to join our next 🌟stellar🌟 mission. 👩‍🚀 We are looking for people who regularly contribute to Django or a Django related package, that want to mentor others. Our next session will be Oct-Nov. 🚀 Come join us and be a cosmic contributor! Express your interest to be a mentor here. 📚 Want to learn more about what it means to be a Navigator: Here's a high-level overview of the role Here's the workbook each Navigator is provided 🤝 Interested people will have to complete a 30 minute meet & greet type interview with organizers. ✋ If you're interested in applying to be a Djangonaut, applications will open and close in September (dates to be determined). The latest information will be posted on our site, djangonaut.space. Please follow our social media accounts or subscribe to our newsletter for announcements. ☄️ We'll see you around the cosmos! Djangonaut Space session organizers