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

Here’s the second 3.14 beta. https://www.python.org/downloads/release/python-3140b2/ Python 3.14 is still in development. This release, 3.14.0b2, is the second 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 3.14.0b3, scheduled for 2025-06-17. 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 In 1897, the State of Indiana almost passed a bill defining as 3.2. Of course, it’s not that simple. Edwin J. Goodwin, M.D., claimed to have come up with a solution to an ancient geometrical problem called squaring the circle, first proposed in Greek mathematics. It involves trying to draw a circle and a square with the same area, using only a compass and a straight edge. It turns out to be impossible because is transcendental (and this had been proved just 13 years earlier by Ferdinand von Lindemann), but Goodwin fudged things so the value of was 3.2 (his writings have included at least nine different values of : including 4, 3.236, 3.232, 3.2325… and even 9.2376…). Goodwin had copyrighted his proof and offered it to the State of Indiana to use in their educational textbooks without paying royalties, provided they endorsed it. And so Indiana Bill No. 246 was introduced to the House on 18th January 1897. It was not understood and initially referred to the House Committee on Canals, also called the Committee on Swamp Lands. They then referred it to the Committee on Education, who duly recommended on 2nd February that “said bill do pass”. It passed its second reading on the 5th and the education chair moved that they suspend the constitutional rule that required bills to be read on three separate days. This passed 72-0, and the bill itself passed 67-0. The bill was referred to the Senate on 10th February, had its first reading on the 11th, and was referred to the Committee on Temperance, whose chair on the 12th recommended “that said bill do pass”. A mathematics professor, , happened to be in the State Capitol on the day the House passed the bill and walked in during the debate to hear an ex-teacher argue: Clarence Abiathar Waldo The case is perfectly simple. If we pass this bill which establishes a new and correct value for pi , the author offers to our state without cost the use of his discovery and its free publication in our school text books, while everyone else must pay him a royalty. Waldo ensured the senators were “properly coached”; and on the 12th, during the second reading, after an unsuccessful attempt to amend the bill it was postponed indefinitely. But not before the senators had some fun. The Indiana News reported on the 13th: …the bill was brought up and made fun of. The Senators made bad puns about it, ridiculed it and laughed over it. The fun lasted half an hour. Senator Hubbell said that it was not meet for the Senate, which was costing the State $250 a day, to waste its time in such frivolity. He said that in reading the leading newspapers of Chicago and the East, he found that the Indiana State Legislature had laid itself open to ridicule by the action already taken on the bill. He thought consideration of such a proposition was not dignified or worthy of the Senate. He moved the indefinite postponement of the bill, and the motion carried. 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 Helsinki, still light at 10pm, Your release team, Hugo van KemenadeNed DeilySteve DowerÅ�ukasz Langa

Only one day late, welcome to the first beta! https://www.python.org/downloads/release/python-3140b1/ Python 3.14 is still in development. This release, 3.14.0b1, is the first 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 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 3.14.0b2, scheduled for 2025-05-27. 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 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 JSON file available for download During the release process, we discovered a test that only failed when run sequentially and only when run after a certain number of other tests. This appears to be a problem with the test itself, and we will make it more robust for beta 2. For details, see . python/cpython#133532 The mathematical constant pi is represented by the Greek letter and represents the ratio of a circle’s circumference to its diameter. The first person to use as a symbol for this ratio was Welsh self-taught mathematician William Jones in 1706. He was a farmer’s son born in Llanfihangel Tre’r Beirdd on Angelsy (Ynys Môn) in 1675 and only received a basic education at a local charity school. However, the owner of his parents’ farm noticed his mathematical ability and arranged for him to move to London to work in a bank. By age 20, he served at sea in the Royal Navy, teaching sailors mathematics and helping with the ship’s navigation. On return to London seven years later, he became a maths teacher in coffee houses and a private tutor. In 1706, Jones published which used the symbol for the ratio of a circle’s circumference to diameter (hunt for it on pages and or ). Jones was also the first person to realise is an irrational number, meaning it can be written as decimal number that goes on forever, but cannot be written as a fraction of two integers. 243 263 here But why ? It’s thought Jones used the Greek letter because it’s the first letter in or perimeter. Jones was the first to use as our familiar ratio but wasn’t the first to use it in as part of the ratio. William Oughtred, in his 1631 (), used to represent what we now call pi. His was the circumference, not the ratio of circumference to diameter. James Gregory, in his 1668 () used instead, where is the radius, making the ratio 6.28… or . After Jones, Leonhard Euler had used for 6.28…, and also for 3.14…, before settling on and popularising for the famous ratio. Ï„ 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 Helsinki as the leaves begin to appear on the trees, Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

Not one, not two, not three, not four, not five, but six releases! Is this the most in a single day? 3.12-3.14 were regularly scheduled, and we had some security fixes to release in 3.9-3.11 so let’s make a big day of it. This also marks the last bugfix release of 3.12 as it enters the security-only phase. See for a chart. devguide.python.org/versions/ Here comes the final alpha! This means we have just four weeks until the first beta to get those last features into 3.14 before the feature freeze on 2025-05-06! https://www.python.org/downloads/release/python-3140a7/ Python 3.14 is still in development. This release, 3.14.0a7, is the last of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: The next pre-release of Python 3.14 will be the first beta, 3.14.0b1, currently scheduled for 2025-05-06. After this, no new features can be added but bug fixes and docs improvements are allowed – and encouraged! This is the third maintenance release of Python 3.13. 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.3 is the latest maintenance release, containing almost 320 bugfixes, build improvements and documentation changes since 3.13.2. https://www.python.org/downloads/release/python-3133/ This is the tenth maintenance release of Python 3.12. Python 3.12.10 is the latest maintenance release of Python 3.12, and the last full maintenance release. Subsequent releases of 3.12 will be security-fixes only. This last maintenance release contains about 230 bug fixes, build improvements and documentation changes since 3.12.9. https://www.python.org/downloads/release/python-31210/ This is a security release of Python 3.11: https://www.python.org/downloads/release/python-31112/ This is a security release of Python 3.10: https://www.python.org/downloads/release/python-31017/ This is a security release of Python 3.9: https://www.python.org/downloads/release/python-3922/ We highly recommend upgrading 3.9-3.13 and we encourage you to test 3.14. On Saturday, 5th April, 3.141592653589793 months of the year had elapsed. 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 sunny and cold Helsinki springtime, Your full release team, Hugo van KemenadeThomas WoutersPablo Galindo SalgadoÅ�ukasz Langa Ned DeilySteve Dower

Today we've issued the 5.2.4 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 Natalia Bidart: 2EE82A8D9470983E

Django has always been more than just a web framework; it’s a testament to what a dedicated community can build together. Behind every Django release, bug fix, or DjangoCon is a diverse network of people working steadily to strengthen our open-source ecosystem. To celebrate our collective effort, the Django Software Foundation (DSF) is excited to share our 2024 Annual Impact Report 🎉 In this report, you’ll discover key milestones, narratives of community folks, the impact of the events running throughout the year, and much more, ramping up to how we’re laying the groundwork for an even more resilient and inclusive Django community. 2024 Annual Impact Report Why we publish this report Transparency is essential for our community-driven organization. Everyone deserves to know how our work and investments translate into real impact. It’s more than just statistics. It’s our way to: Show how your contributions make a difference, with vibrant highlights from the past year.  Reflect on community progress, recognizing the people and ideas that keep Django thriving. Invite more individuals and organizations to get involved. Looking ahead: call to action As we make progress through 2025, the Django Software Foundation remains dedicated to strengthening the ecosystem that supports developers, contributors, and users around the world. With a growing network of working groups, community initiatives, and the commitment of volunteers, we’re focused on nurturing the people and executing ideas that make Django what it is: the web framework for perfectionists with deadlines.  Help keep this momentum strong by supporting Django through any of the following ways: Donate to Django to support future development Convince your company to become a Corporate Member Join the Foundation as an Individual Member Get involved with the working groups Join our community on the Django Forum or Discord server. Follow and re-share our posts on Mastodon, on Bluesky, or on X. Follow our page on LinkedIn. Donate to Django Thank you, everyone, for your dedication and efforts. Here’s to another year of collaboration, contribution, and shared success! Any feedback or questions about our report? Come say hi in our feedback thread on the Django forum.

They’re now all available to watch on YouTube, with a dedicated playlist ⭐️ DjangoCon Europe 2025 Dublin. For more quality Django talks in 2025, check out our next upcoming events! DjangoCon Africa 2025 Aug. 11, 2025 | Arusha, Tanzania 🇹🇿 DjangoCon US 2025 Sept. 8, 2025 | Chicago, Illinois, USA 🇺🇸 DjangoDay India Nov. 2, 2025 (tentative) | Bangalore, India 🇮🇳 All the DjangoCon Europe talks Welcome Session Keynote: Django needs you! (to do code review) End-to-end testing Django applications using Pytest with Playwright Turn back time: Converting integer fields to bigint using Django migrations at scale Data-Oriented Django Drei The fine print in Django release notes Django + HTMX: Patterns to Success How to solve a Python mystery Bulletproof Data Pipelines: Django, Celery, and the Power of Idempotency Logs, shells, caches and other strange words we use daily Day 1 Lightning Talks How to Enjoy Debugging in Production KEYNOTE: The Most Bizarre Software Bugs in History Passkeys in Django: the best of all possible worlds How we make decisions in Django 100 Million Parking Transactions Per Year with Django One more time about µDjango Steering Council introduction Supporting Adult Career Switchers: The Unbootcamp Method How to get Foreign Keys horribly wrong in Django Zango: Accelerating Business App Development with an Opinionated Django Meta Dynamic models without dynamic models Evolving Django: What We Learned by Integrating MongoDB Feature Flags: Deploy to some of the people all of the time, and all of the Day 2 Lightning Talks KEYNOTE: Django for Data Science: Deploying Machine Learning Models with Django The incredible Djangonaut Space project Anatomy of a Database Operation One Thousand and One Django Sites Django Admin at Scale: From Milliseconds to Microseconds 🚀 Just-in-Time Development with Django and HTMX: Faster, Leaner, and Smarter Europe, Django and two-factor authentication Closing session Day 3 Lightning Talks

For June 2025, we welcome Elena Williams as our DSF member of the month! ⭐ Elena is a dedicated member of the Django community. She is part of the Code of Conduct Working Group and she is a Django Girls organizer in Australia. She has been a DSF member since July 2014. You can learn more about Elena by visiting Elena's website and her GitHub Profile. Let’s spend some time getting to know Elena better! Can you tell us a little about yourself (hobbies, education, etc) My background is that I was always interested in computers, though my parents were more creative types, my Dad was an Architect (of built structures). When I was a kid we had computers for CAD around the house before it was common. I was always into STEM subjects, but unfortunately in that era for girls to do engineering it was a bit too hostile for me, so I trained in finance instead and worked in that industry (finance and banking, MNE orgs) for nearly a decade. I kept coming back to coding and was always building computers, and was obsessed with the internet as a technology from pretty early on. Just after I discovered Django I did a Masters in Computing at ANU. To this day my main hobbies are programming/webdev (very much a person who codes for fun) and the open source community. My persistent other hobbies are hackspace activities, I like CNC and laser stuff, but will pick up any and all tools/mediums and give them a go, lately been spending time with blender and cabinetry. When I can, I like to get away to snowboard or kitesurf, and this wild Australian long distance endurance navigation sport called rogaining. Really at the moment I’m mostly focussed on being a parent (which is an awesome experience), my friends (mostly python related), my job and working on the community here in Australia. With my family we go camping/hiking more than most. I’ve also continued to be a sessional academic at ANU teaching software engineering for many years. How did you start using Django? Golly, I’ve been using Django forever. I’d started doing web stuff in the early ‘00s and worked in a range of languages and paradigms. I was working in a physics research institute at a high profile university in Australia doing web stuff and made friends with a bunch of the doctoral students. In around 2007, one of these students, and my good mate, Dave, randomly recommended this new framework Django and Python (and emacs also actually but that’s a different story). Basically I got into it immediately and never looked back and went on to build a career around Django (actually Dave later gave up physics and did the same thing too). I’ve been engaged with the Python and Django communities to varying degrees since about 2011 as well. To be honest when I discovered the language and the framework I really didn’t expect to still be passionate about them all these years later but I really am! Hopefully I can continue to be well into the future also. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? Over the years (being a curious person) I’ve worked with many many web frameworks and technologies, the vast majority of the big ones. In recent years I’ve been spending time with FastAPI and SQLAlchemy as well as non-python technologies. Django is better though. Not using Django as much at the moment makes me love it even more and realise how lucky we are with such a well designed and well supported framework. It’s not perfect but it’s outstanding. Having said that: at a technical level I’d love to have “cheaper” ways (in every sense) to deploy. Even though deployment methods have changed beyond recognition several times over the years, I always thought this would get easier over time and am kind of surprised that it hasn’t. Very specific to me is that I need Django to have stronger support for many database schemas in the same project, but honestly this is just a specific problem I have inherited in a project at the moment, but it’ll pass eventually. What projects are you working on now? Over the last few years I’ve helped organise a number of events, including PyConAU, though realised I’d been taking on too many projects and trying to pull back actually! Still: Internationally I’m on DSF CoC with a great team. Nationally this year I’ve been serving on the committee of our main Australian open source foundation body, Linux Australia, as well as working in a small team trying to bring together all of the Australian python user groups under a banner we hope to call Python Australia and I’ve had a keen interest in python user groups around the world. In my home town I’ve been organising our local user groups for some time with an awesome team, as well as our fantastic local PyLadies. For work I’m flat-chat working in a senior role on a Platform team in a small data company that provides “critical digital infrastructure” for Australia. Though my most important project of all at the moment really is my family, and I do really prioritise my friends and being healthy nowadays. I’m an avid hackerspace person and do have a couple of purportedly active projects (I’m obsessed with maps among other things) but these are relatively neglected at the moment as I just don’t have the bandwidth. Which Django libraries are your favorite (core or 3rd party)? I just love the ORM. We’re so spoiled in the Django community we don’t realise how mature and feature-rich the ORM is. Maybe I’m biased because I’ve been using it for so long I just “think” in Django ORM and I’ve been working away from it lately. It’s such a (comparative) pleasure to use. You can nit-pick at it but compared to anything else it’s so beautifully thought through. The admin was the Django “killer app” in 2008 and I’d argue still is in 2025. To be some dozens of seconds away from a custom CMS backend at any time is still magical. Pony magical. It’s still as impressive as ever to show off to people. Also in the same way that Guido says python makes a great calculator: Django makes a great quick tool for really fast data munging, can’t describe how liberating it feels using it for this purpose. Writing tests in Django is under-rated too. There are so many amazing 3rd party libraries, too many to mention. For shout-outs I don’t think I have any projects without Debug Toolbar. The 3rd party caching libraries Memcache and Redis are both great. I’m also usually happy when I turn on Celery, and excited to see DEP-0014 on its way. Danny and Audrey’s Django Cookiecutter project is a great reference even if you don’t take the whole enchilada. What are the top three things in Django that you like? I’ve been lucky to generally have had a pretty great time with Django. Generally I’ve used it for projects where it was a really good fit and so it wasn’t painful. As such I like weird little quirky things about Django. Haters-can-hate but I actually really like a bunch of this controversial stuff, for example I like settings.py as a pattern for projects that aren’t out of control; I enjoy using and customising the management commands framework; I think Meta class as an approach to that type of awkward problem is neat; I’ve generally had a pretty nice time with the template language; I dig into utils and reuse them probably more often than most; ORM and the Tests obviously (it’s trivial to plugin pytest of course). Everything is a trade-off in software engineering and while I’m very biased: I just like the trade-offs that Django has chosen, they’re some of the best-in-class. The top 3 things though? This is tough. I just like it. To nail down actual answers though: the framework workflow overall; that the project has stayed so consistently high quality and battle-hardened for so many years; and the community and my friends (shout out sp-wg) I know you have start Django with one of the first version, what do you think of the evolution of the framework? This is a great question! Thanks for being interested in this history, the Django history is a nice story of having good values and persisting and this actually being successful over the long run. For me there’s all the “back in my day” stuff that’s not obvious now, like Python not being taken seriously as a “real” programming language, let alone javascript, but now those tides have very much turned, and web development is considered extremely respectable and high profile, which was unimaginable when I started. Django started in Web1.0 (whatever that meant), and actually grew substantially during Web2.0 and now even in the modern Web3 era is kind of establishing itself into being part of the backbone of the large parts of the internet that aren’t obvious. Thibaud has a list he maintains of websites that he believes use Django, this is great if you haven’t seen it. One of the most impressive parts of the evolution has been how decisions have been made and implemented. In normal “work” you just have to make things as fast as possible and endlessly add features consequences-be-damned. Open source gets to be fundamentally the opposite. Traditionally one of the defining characteristics of Open Source is that “time is no object”. That is good design and implementation can be allowed the time to breathe and be excessively thought through. There is no rush or deadline. While there’s always conflict and drama I think there has been less so in Django than in most other projects as design decisions have been painstakingly threshed out and perfected in mailing lists, tickets, DEPs and forums over the months and years it takes to make them. The people inside see the drama but we’re in the news almost never compared to most projects in the same space. The point is that hypothetically it’s possible to try to make the best possible design decisions. In practice most projects don’t do this, but I think Django has demonstrated exemplary maturity in trying to pursue this ideal, and is regularly recognised for it. The original founding team deserve full credit for instilling this culture and each successive group of stewards deserve credit for preserving it. There have (and always will be) missteps. For example CBVs are such an obviously good idea on paper, but in practice people don’t think so. On the other hand Andrew Godwin’s implementation of migrations back in the day, that was completely re-writing South from scratch, was truly lovely, even though it was a battle to get to the point of having migrations at all. There’s the history around the db module, which pretty much everyone was too scared to touch after Malcolm died until there were some impressive breakthroughs in it during the “under the hood” sessions not long after DjangoGirls people started coming on board. Django consciously has decided to be extremely considered in its adoption of change and this has been a great thing. Other frameworks have generally been more cavalier, while Django has been steady, careful and reliable. The other full-feature frameworks are kind of in decline, or have hurt themselves by too-much-change-too-fast, while Django has steadily slowly grown and is the trusty go-to tool for a certain kind of job. Now moving forward I see focus on the very subtle things that make the framework nicer to use and understand, On just making the core capabilities better and more reliable and performant, and only very very carefully adding features. In an age where so much quality degradation is occurring, it inspires hope that projects like Django can persist as beacons of high quality, held together by a small group and big community of thoughtful, caring individuals. Hopefully this is something we can continue for a long time into the future also! You are part of the Code of Conduct working group, how is it to work with the working group? Do you have space available for new members? What does it require according to you? Code of Conduct WGs are slightly niche and exposed to a certain kind of work and responsibility. Not to mention that respecting many sensitives and view-points is necessary. It also means having the guts to tell people “that’s not how it’s done here” when it needs to be said. Personally it’s a kind of work I’ve grown to be passionate about. I truly believe having a great culture is at the core of community (and really anything good) and can be a complex balancing act of competing factors and emotions. It’s certainly not the kind of thing everyone is into, but if you are, the WG is looking for more diversity, if nothing else it’s tending slightly older at the moment. Having said that: Within all of the open source communities from local to international levels there’s always space for people who are willing to turn up and help! Join your local community! Find the parts of community that “speak” to you. Maybe it’s starting a meetup, helping your local conference, running a DjangoGirls. Maybe it’s something engineer-related like finally adding something to an open source library that you’re into, adding some beginner docs somewhere, or engaging with Djangonaut Space. Maybe it’s something online like helping out in forum.djangoproject.com, Reddit or Discord. As organisers we have this cheat code for finding new people to invite to help more, it’s called “looking for chair-stackers”, that is people who engage to help in the little ways, such as helping stack chairs at the end of an event or generally pack down, wipe up, carry boxes or put things away. Or online: people who go out of their way to try to understand and chip in to manage extra rules, or answer the unanswered thing that’s been sitting there for a while. Or people who just ask “can I help out with that?” when the organisers seem tired or stressed out. Having people around who help in these ways has huge value and has been the beginning of many people being involved in communities and making life-long friends and connections. Now more than ever though, it’s so important to connect to your community. We are stronger, better and healthier when we are connected to and relied on by other people and we have others we can share our experiences with. Particularly us computer people tend not to be as good with connecting with other people, but everyone should find their way to get out and connect! It’s sometimes hard but it’s always better. You have organized many DjangoGirls in Australia, how did you start? Do you have any advice for someone who would like to organize a DjangoGirls event? In 2014 I was living in Perth, Australia, where Russell Keith Magee is based and we had a budding Python/Django User Group. At one of the meetings news emerged about how Ola and Ola were running this thing called “DjangoGirls” at EuroPython in a few weeks. PyConAU was scheduled a couple of weeks after this. I was like, that’s a great idea, I can absolutely have a go at doing that and emailed them immediately asking if I could copy their materials and plan. We pulled it together with an amazing bunch of people and I think this was technically the 2nd DjangoGirls event ever. In the following years I’ve been involved in many more, including the first North American DjangoGirls. From our Perth series of events a successful organisation was spun off called SheCodes. In the more-than-a-decade since then the world has changed so much! Particularly in the tech world. I would say specifically for DjangoGirls events, they are very region specific. My first advice for organising an event in your region is to see if there’s been one previously and reach out to the event organisers, or at least the nearest organisers – I think these days there are few places on earth that haven’t had a DjangoGirls event nearish-by. The resources on the website are actually great for getting going and the international DjangoGirls team are lovely, but also always looking for more help. Where I live now, back in the capital, Canberra, we are very well supported for education services. We held a DjangoGirls event a couple of years ago, but for the attendees what emerged was that what we really wanted was just to connect with other technical women. Now what has been very successful for us is an ongoing PyLadies/Women’s Software group who meet up regularly and talk about things that matter to our experience. We use the “lean-coffee” model and it’s been unexpectedly functional. This has been one of the best groups I’ve ever been in with a range of technical women regularly sharing our weird and statistically unusual experiences together, it feeds the soul, and is strongly recommended if you don’t participate in a group like this already. Is there anything else you’d like to say? A final shout out to the original leaders of the Django community, for me personally Russell, Jeff, Jacob, Andrew and Baptiste in particular, but everyone who has persisted over the years in just turning up over the long haul and keeping our part of the world as beautiful as can be. My friends Dave, Matt and Jonah. Thibaud is a great president right now. Rarely is there a dedicated Django person who is not absolutely delightful and I feel both proud and honoured to be part of this community. A big thank you to everyone (especially you Sarah! And all the Sarahs, Natalias, Lillys and Olas) who help to make Django what it is. Thank you for doing the interview, Elena !

Following the June 4, 2025 security release, the Django team is issuing releases for Django 5.2.3, Django 5.1.11, and Django 4.2.23 to complete mitigation for CVE-2025-48432: Potential log injection via unescaped request path (full description). These follow-up releases migrate remaining response logging paths to a safer logging implementation, ensuring that all untrusted input is properly escaped before being written to logs. This update does not introduce a new CVE but strengthens the original fix. We encourage all users of Django to upgrade as soon as possible. Affected supported versions Django main Django 5.2 Django 5.1 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 5.2, 5.1, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-48432: Potential log injection via unescaped request path On the main branch On the 5.2 branch On the 5.1 branch On the 4.2 branch The following releases have been issued Django 5.2.3 (download Django 5.2.3 | 5.2.3 checksums) Django 5.1.11 (download Django 5.1.11 | 5.1.11 checksums) Django 4.2.23 (download Django 4.2.23 | 4.2.23 checksums) The PGP key ID used for this release is : 3955B19851EA96EF

The Django Software Foundation is announcing a call for Django Fellow applications. A Django Fellow is a contractor, paid by the Django Software Foundation, who dedicates time to maintain the Django framework. The Fellowship program was started in 2014 as a way to dedicate high-quality and consistent resources to the maintenance of Django. The Django Software Foundation currently supports two Fellows –Natalia Bidart and Sarah Boyce– and has approved funding for a new full-time Fellow. This position will be initially for a period of one year, but may be extended depending on fundraising levels. Beyond keeping Django running, a fellow is a representative of Django itself. They embody the welcoming culture of Django and aid the community to progress the framework. Fellows are often called upon to speak at Django conferences and events. They are also usually leading Django Sprints occurring in conferences or other setups. Hence a Django Fellow often engages in both informal and formal mentorship. Responsibilities Fellow duties include (but are not limited to): Monitoring security reports and ensuring security issues are acknowledged and responded to promptly Fixing release blockers and helping to backport fixes to these and security issues Ensure timely releases including being a release manager for a new version of Django Triaging tickets on Trac Reviewing and merging pull requests Answering contributor questions on the Forum Helping new Django contributors land patches and learn our philosophy Requirements A Django fellow reviews a very large amount of Django contributions. This requires knowledge in every aspect of web development that the Django framework touches. This turns out to be an intimidatingly-large list of technical topics, many of which are listed below. It’s not our expectation that you come into the job knowing everything on this list! We hope you’ll have solid experience in a few of these topics, particularly some of the “core” technologies important to Django (Python, relational databases, HTTP). But we fully expect that you’ll learn most of this on the job. A willingness to learn, and a demonstrated history of doing so, is more important than comprehensive knowledge. The technical topics you can expect to work on includes (and is not limited to): SQL and Databases: SQLite, MySQL, Postgres, Oracle Technical Documentation Javascript CSS Semantic HTML Accessibility UI/UX design (Web and CLI) Python async Python features (and versions), compatibility matrix, etc. Everything around HTTP Security best practices There are also: Complex processes which need adhering to Multiple discussions which need opinions and direction Requirements for both formal and informal mentorship And required professional skills such as: Conflict resolution Time management and prioritization expertise Ability to focus in short periods of time and do substantial context switches Self-awareness to recognize their own limits and reach out for help Relationship-building and coordination with Django teams, working groups, and potentially external parties. Tenacity, patience, compassion and empathy are essential Therefore a Django Fellow requires the skills and knowledge of a senior generalist engineer with extensive experience in Python and Django. Open source experience, especially in contributing to Django, is a big plus. Being a Django contributor isn't a prerequisite for this position — we can help get you up to speed. We'll consider applications from anyone with a proven history of working with either the Django community or another similar open-source community. While no geographical location is required, we have a slight preference for timezones between around -8 and +3 UTC to allow for better working hours to overlap the current fellows. If you're interested in applying for the position, please email us at fellowship-committee@djangoproject.com describing why you would be a good fit along with details of your relevant experience and community involvement. Lastly, please include at least one recommendation. The current hourly rate for a fellow is $82.26 USD. Applicants will be evaluated based on the following criteria: Details of Django and/or other open-source contributions Details of community support in general Understanding of the position Clarity, formality, and precision of communications Strength of recommendation(s) Applications will be open until midnight AoE, 1 July, 2025, with the expectation that the successful candidate will start around August 1, 2025.