First things first: the next djangocon.eu will be in… Warsaw, Poland!
Everyone could suggest questions via google moderator and twitter. The best ones were asked to the core devs present at the conference: Karen, Jannis, Rick, Jacob, Matthew (if I got the names right).
PyDanny moderated it.
The good thing: it went pretty smooth, there was no major hickup. We still have to figure out minor issues: work in progress.
People are submitting pull requests faster than the core devs expected. Fun.
Luke Plant really said class based views were a mistake. There are already people discussing fixing/improving things due to that.
Function based views are still possible.
The CBVs are too generic. They are not stripped down enough. They are almost too flexible. But remember… the old function based generic views were also horrible.
There was a show of hands. Just two people used the function based generic views. Lots more are using the CBV generic ones. Ok!
The web is developing every day. So the necessary feature set changes. Some of the new features might be well-maintainable outside of the core. But some might be good to include in django so that users get it immediately.
New contributions are, as a first rule, best originally kept outside of the core.
Django has simply originally made the choice of being a full stack framework, so that’s what we are.
Creating reusable apps. How to do it? Best practice? The lack of clarity is a stumbling block to new developers. There’s an old blog post that seems to be the best resource.
There should be something in django’s own docs.
You can help a lot of people by making such a doc!
There is no code yet. There’s community feedback needed. Is there new functionality that needs to go in? There are various ideas. Open question, still.
The design is hard. Not just the visual one, but the interaction design and the technical design.
Design is incompatible with a community process. Design by committee is wrong. So an individual needs to do it, but all the people we trust are hard at (paying) work. Open source cannot do good design.
The above is about a from-the-ground re-imagining of the admin. There are, however, a ton of small things that we can improve in the current admin that can be done just fine as a community.
There’s still work to be done. But we also have to make it easier for everyone to port their own apps.
Dependencies (PIL, mysqldb and so) are “just a matter of time”.
As soon as we get the unittests all running on python 3, we’ll probably push out some pre-alpha preview of django 1.5 to get people to test it on python 3.
There is a pretty good chance that django 1.5 will support python 3. Not every dependency might work, though.
It just stalled. There’s no particular reason.
We need more help. Most core devs are simply only used to relational databases. So if you’re into couchdb or mongodb: apply.
Jacob always uses (and teaches) south. “Just look at the migration file, it works, but don’t ever touch it or look at it again”. It isn’t pretty.
The possible fullname/firstname change? We cannot do that until we have migrations in the core…
If you need to do it well, you really need to do it in core. All other options will be dirty hacks, as it touches too many places.
Django uses tread.local in a couple of places, that’s basically the problem. So if you want to use it with gevent, you need to monkey patch.
6 years ago you could have asked “aren’t web standards only relevant for a few sites”? So… the real-time web will be very important in the future.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
