Django Good Practices

[Editado em 2011/03/27]: melhor explicado e detalhado o primeiro tópico.

 Depois dos tópicos de antipadrões com Django (http://pythonsmalltalk.blogspot.com/2011/03/discussao-sobre-django-internet-e.html), agora um tópico de boas práticas.

• Usar filter e exclude somente dentro de managers ou models: Com django é tão fácil fazer query que acabamos inserindo filters e excludes em tudo quanto é local, tais como views e forms, o que é uma ideia terrível. Prejudica a testabilidade do código, mistura responsabilidades dos objetos etc.
• Dar nomes às urls e usar reverse e a tag url: Usar urls hard-coded além de prejudicar a manutenção, ainda dificulta i18n. Além disso, a aplicação pode deixar de ser um "pluggable", ou seja, dificilmente poderá ser reaproveitada em outros projetos.
• Utilizar select_related sempre que possível/necessário para otimização (http://docs.djangoproject.com/en/1.2/ref/models/querysets/#select-related)
• Usar distinct em buscas que envolvem várias tabelas. Mais comumente quando são usados campos many to many para buscas. Isso é pra evitar que uma busca traga registros repetidos. Chatices de SQL que são propagadas nos resultados das buscas. (http://docs.djangoproject.com/en/1.2/ref/models/querysets/#distinct)
• Criar Custom Fields caso um field siga um padrão (http://docs.djangoproject.com/en/1.2/howto/custom-model-fields)
• Sempre dar redirect depois de salvar um formulário (básico de qualquer framework Web).
• Não utilizar o arquivo tests.py. Criar uma pasta tests e adicionar arquivos de teste para arquivo da aplicação.
• Há várias maneiras de organizar o settings. Uma básica e boa é criar (pelo
  menos) um arquivo de settings para desenvolvimento e um para produção.