Django technical design panel
Note beforehand: djangocon.us returns to Portland in
Question: is there any part of the API that you’d like to change but can’t
because of backward compatibility?
- Yeah, all of it. It is 6 years old now. But most things are changeable in
a backward compatible way, however. One specific part: the middleware API.
And urlconfs aren’t that nice.
- Internals of templatetags. Nothing really fundamental, but it needs to be
cleaned up and fixed. Here, too, the backward compatibility doesn’t really
prevent it from happening.
- Model validation is messy and complicated.
- i18n is harder than it has to be.
Question: what single feature would you like to see most in Django that
already exists in framework X?
- Handling asynchonicity better.
- Ruby has a nicer way of creating new applications: you can point ruby’s
manage.py startapplication at a url with various templates.
- Look at microframeworks. They’re fun.
Question: Are there parts of the wider Python ecosystem that we can do a
better job of integrating with.
- We should be actively involved in the Python standards process as one of the
- We’re already pretty involved in distribute, pip, virtualenv and so. That’s
a good example.
Question: What are the plans for python 3?
- We haven’t made any plans for 2017 yet.
- We’re slowly dropping older releases. Probably python 2.4 sticks around
in django 1.3, though.
- There has been work done on a python 3 port. Apparently the tests already
run, though only 60% succeed. He considered 50% already a huge success, so
they (=students at a canadian university, if I heard correcly) did a good
- Python 3 support will depend on an influx of new developers.
Question: are there plans for further standardization on “missing feature”
apps (like South)?
- No real believe in the benefit of adding many more apps to contrib. Or with
voting on it.
- Drupal has a good vote-on-your-plugin site. Several people tried getting
something off the ground for Django, but nothing that’s widely used.
- Finding the right apps is not only a Django problem: it is a problem for the
whole of python!
- If you have a good idea and if you’re limited by web space or so? Ask Jacob
Question: how do you think the community can better get involved?
Regarding this, I mentioned the difference between Plone
and Django. Django has a handful of core committers and loads of users.
Plone’s user base is smaller, but the core committer count is much higher.
Plone has 80-100 people with core commit access. Perhaps 30-40 do some
sizable work every release with a couple of people taking up most of the work.
The difference stroke us when discussing it with some Plone developers during
- We’re extremely picky about adding commit access. You have to think the
same way as we do. It allows us to work as a team. There are other
projects that work in a different ways, but this is the way we picked.
Changing it would mean major changes to how we go about our work.
- Who do we pick? If we’d up our committer count to 40, we’d need to add 30.
I know 10 from the top of my head, but the rest is harder. Who do you
include? Who do you exclude? How do you know you can trust them?
- Django’s trunk is extremely stable. Many people work directly from trunk.
That stability and quality needs to be maintained.
Question: what about breaking up contrib into separately released packages?
- Twisted sets a good example by breaking itself up as separate packages.
- It would be nice to be able to release certain parts (template system,
contrib.auth) as separate packages so that they can be released more often.
Question: what are the best python practices for django devs coming from
- Look at other python frameworks to find out where django is different. Play
with them and you’ll be better in django.
Question: do you think django should do more to steer devs in the right
direction regarding scalability, caching?
- Documentation. That’s the biggest. Documentation about best practices.
- Documentation has hard points. A good dev uses virtualenv, but you don’t
want to have to explain it to a new dev right away.
- Buildout solves all Jacob’s packaging and
deployment problems. Works great. Better than virtualenv. But it is
horrible to have to explain to a new developer how to use it. So he says
“virtualenv” all the time, but uses buildout instead. There’s a big need
for better documentation.
Question: how do you pick stuff for inclusion in core?
- People have to present items for inclusion.
- For instance, go through all the management commands on pypi and see which
ones ought to be included in core.
Question: what about official dvcs mirrors?
- There are various mirrors (hg, bzr, git). Some aren’t really being used or
- Mercurial’s (hg) mirror is now up-to-date (since yesterday) and
hash-compatible with subversion.
- We could advertise the effectively-official dvcs mirrors on the website.
- Use one of those semi-official mirrors for the dvcs of your choice.
(About the photo: 1990 school trip to Berlin)