Django technical design panel¶

Note beforehand: djangocon.us returns to Portland in September 2010!

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 version of 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 major players.

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 job.

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 and he

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 lunch.

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 non-python background?

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 updated.

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)