August 21, 2012
DjangoCon US (3rd-8th September), to be held in Washington D.C., is less than two weeks away.
The packed schedule of talks has been posted, as has the list of tutorials to be held on the day before the conference. At the conclusion of formal conference proceedings, we'll be sprinting for 2 days.
The keynote speakers have also been announced. Eric Sterling, President of the Criminal Justice Policy Foundation will be speaking on the challenge of building platforms for political power and change; Geoff Schmidt, a principal developer of Meteor, will be sharing insights from Meteor's design that could benefit Django and discuss how Meteor and Django can work together to build the real-time APIs of the future; and Selena Deckelmann will be speaking on reforming computer science education.
Tickets are still available. Sign up, join in and enjoy everything that the biggest Django event has to offer.
August 19, 2012
A little bit of history
In May, Vinay Sajip published a fork proving that it was possible to support both Python 2 and 3 with a single codebase, and pass the entire test suite. This fork built upon earlier efforts by Martin von Löwis.
Shortly after, the core team decided to use six as a compatibility layer, rather than an ad-hoc library. The goal was not only to cover Django's needs, but also to choose a solution that would work for the ecosystem at large. Starting with Django 1.5, six will be bundled as django.utils.six, and thus available for all Django applications that use the same porting strategy as Django itself.
The first actual step towards Python 3 support was to remove the u prefixes of unicode strings and add the unicode_literals future import. This change was committed at the DjangoCon Europe sprints in July.
Then the biggest part of the work happened over the last few weeks, with hundreds of commits updating various parts of Django.
The core team focused on writing Python 3 code with Python 2 compatibility, rather than the opposite, in order to future-proof the code base. In order to avoid confusion, functions and classes whose name included string or unicode were renamed to bytes and text respectively. As a consequence, the port was significantly more invasive than Vinay Sajip's proof of concept.
On the bright side, since string encoding and decoding operations need to be correct under Python 3, several approximations were corrected during the porting effort. Even though the compatibility code adds some noise, the resulting code is cleaner in many places.
I'd like to thank all the community members and core developers who contributed to this huge project.
Does this mean that Django is ready to use with Python 3? Not yet!
First, Django has received next to none real-life testing under Python 3. Consider the code pre-alpha.
Then, while the core team did its best to eliminate bugs, the test suite doesn't cover all possible uses of Django. That's where the community comes in.
We need your help to test the development version of Django, not only to report bugs on Python 3, but also regressions on Python 2. While Django is very conservative with regards to backwards compatibility, mistakes are always possible, and it's likely that the massive refactoring work introduced some regressions.
Finally, Django is much more than a web framework — it's an ecosystem of pluggable applications. At this point, few third-party applications support Python 3. Authors are strongly encouraged to port their pluggable applications as soon as possible. Porting tips are available in the documentation.
August 7, 2012
Following last week's security releases, we've received a few questions, and also noted some confusion.
To answer those questions and clear up any confusion, today we've added a new section to the Django documentation, outlining Django's security policies in detail. Our hope is for this document to be a one-stop shop for any questions you may have about how the Django project handles security issues; if there's anything missing from it, please let us know. And if you need a convenient, easy-to-remember URL, djangoproject.com/security/ redirects to this document.
In particular, we'd like to encourage all users of Django to read the sections on who receives security notifications, how to request them and what the criteria are for inclusion on our security notification list. For obvious reasons, that list simply cannot include most users of Django, and must be kept small in order to serve its intended purpose.
We also strongly encourage all users of Django to subscribe to the django-announce mailing list, which is a low-traffic list serving only to announce new Django releases.
August 1, 2012
Following Monday's security releases, we began receiving reports that one of the fixes applied was breaking Python 2.4 compatibility for Django 1.3. Since Python 2.4 is a supported Python version for that release series, today we are issuing the following new release:
The patch for this can be viewed in our git repository as well, for review purposes.
Users of the Django 1.3 release series who are on Python 2.4 are encouraged to upgrade to this new package; other users of Django 1.3 are unaffected.