Django technical design panel¶

Tags: django, djangocon, plone

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)