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.
East Berlin in 1990

(About the photo: 1990 school trip to Berlin)

blog comments powered by Disqus
 
vanrees.org logo

About me

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.

Weblog feeds

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):