Favorite Django Tips & Features?
PythonDjangoHidden FeaturesPython Problem Overview
Inspired by the question series 'Hidden features of ...', I am curious to hear about your favorite Django tips or lesser known but useful features you know of.
- Please, include only one tip per answer.
- Add Django version requirements if there are any.
Python Solutions
Solution 1 - Python
I'm just going to start with a tip from myself :)
Use os.path.dirname() in settings.py to avoid hardcoded dirnames.
Don't hardcode path's in your settings.py if you want to run your project in different locations. Use the following code in settings.py if your templates and static files are located within the Django project directory:
# settings.py
import os
PROJECT_DIR = os.path.dirname(__file__)
...
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
...
TEMPLATE_DIRS = (
os.path.join(PROJECT_DIR, "templates"),
)
Credits: I got this tip from the screencast 'Django From the Ground Up'.
Solution 2 - Python
Install Django Command Extensions and pygraphviz and then issue the following command to get a really nice looking Django model visualization:
./manage.py graph_models -a -g -o my_project.png
Solution 3 - Python
Use django-annoying's render_to
decorator instead of render_to_response
.
@render_to('template.html')
def foo(request):
bars = Bar.objects.all()
if request.user.is_authenticated():
return HttpResponseRedirect("/some/url/")
else:
return {'bars': bars}
# equals to
def foo(request):
bars = Bar.objects.all()
if request.user.is_authenticated():
return HttpResponseRedirect("/some/url/")
else:
return render_to_response('template.html',
{'bars': bars},
context_instance=RequestContext(request))
Edited to point out that returning an HttpResponse (such as a redirect) will short circuit the decorator and work just as you expect.
Solution 4 - Python
There's a set of custom tags I use all over my site's templates. Looking for a way to autoload it (DRY, remember?), I found the following:
from django import template
template.add_to_builtins('project.app.templatetags.custom_tag_module')
If you put this in a module that's loaded by default (your main urlconf for instance), you'll have the tags and filters from your custom tag module available in any template, without using {% load custom_tag_module %}
.
The argument passed to template.add_to_builtins()
can be any module path; your custom tag module doesn't have to live in a specific application. For example, it can also be a module in your project's root directory (eg. 'project.custom_tag_module'
).
Solution 5 - Python
Virtualenv + Python = life saver if you are working on multiple Django projects and there is a possibility that they all don't depend on the same version of Django/an application.
Solution 6 - Python
Don't hard-code your URLs!
Use url names instead, and the reverse
function to get the URL itself.
When you define your URL mappings, give names to your URLs.
urlpatterns += ('project.application.views'
url( r'^something/$', 'view_function', name="url-name" ),
....
)
Make sure the name is unique per URL.
I usually have a consistent format "project-appplication-view", e.g. "cbx-forum-thread" for a thread view.
UPDATE (shamelessly stealing ayaz's addition):
This name can be used in templates with the url
tag.
Solution 7 - Python
Use django debug toolbar. For example, it allows to view all SQL queries performed while rendering view and you can also view stacktrace for any of them.
Solution 8 - Python
Don't write your own login pages. If you're using django.contrib.auth.
The real, dirty secret is that if you're also using django.contrib.admin, and django.template.loaders.app_directories.load_template_source is in your template loaders, you can get your templates free too!
# somewhere in urls.py
urlpatterns += patterns('django.contrib.auth',
(r'^accounts/login/$','views.login', {'template_name': 'admin/login.html'}),
(r'^accounts/logout/$','views.logout'),
)
Solution 9 - Python
Context processors are awesome.
Say you have a different user model and you want to include that in every response. Instead of doing this:
def myview(request, arg, arg2=None, template='my/template.html'):
''' My view... '''
response = dict()
myuser = MyUser.objects.get(user=request.user)
response['my_user'] = myuser
...
return render_to_response(template,
response,
context_instance=RequestContext(request))
Context processes give you the ability to pass any variable to your
templates. I typically put mine in 'my_project/apps/core/context.py
:
def my_context(request):
try:
return dict(my_user=MyUser.objects.get(user=request.user))
except ObjectNotFound:
return dict(my_user='')
In your settings.py
add the following line to your TEMPLATE_CONTEXT_PROCESSORS
TEMPLATE_CONTEXT_PROCESSORS = (
'my_project.apps.core.context.my_context',
...
)
Now every time a request is made it includes the my_user
key automatically.
Also [signals][1] win.
I wrote a blog post about this a few months ago so I'm just going to cut and paste:
Out of the box Django gives you several signals that are incredibly useful. You have the ability to do things pre and post save, init, delete, or even when a request is being processed. So lets get away from the concepts and demonstrate how these are used. Say we’ve got a blog
from django.utils.translation import ugettext_lazy as _
class Post(models.Model):
title = models.CharField(_('title'), max_length=255)
body = models.TextField(_('body'))
created = models.DateTimeField(auto_now_add=True)
So somehow you want to notify one of the many blog-pinging services we’ve made a new post, rebuild the most recent posts cache, and tweet about it. Well with signals you have the ability to do all of this without having to add any methods to the Post class.
import twitter
from django.core.cache import cache
from django.db.models.signals import post_save
from django.conf import settings
def posted_blog(sender, created=None, instance=None, **kwargs):
''' Listens for a blog post to save and alerts some services. '''
if (created and instance is not None):
tweet = 'New blog post! %s' instance.title
t = twitter.PostUpdate(settings.TWITTER_USER,
settings.TWITTER_PASSWD,
tweet)
cache.set(instance.cache_key, instance, 60*5)
# send pingbacks
# ...
# whatever else
else:
cache.delete(instance.cache_key)
post_save.connect(posted_blog, sender=Post)
There we go, by defining that function and using the post_init signal to connect the function to the Post model and execute it after it has been saved.
[1]: http://docs.djangoproject.com/en/dev/topics/signals/ "Django Signals"
Solution 10 - Python
When I was starting out, I didn't know that there was a Paginator, make sure you know of its existence!!
Solution 11 - Python
Use IPython to jump into your code at any level and debug using the power of IPython. Once you have installed IPython just put this code in wherever you want to debug:
from IPython.Shell import IPShellEmbed; IPShellEmbed()()
Then, refresh the page, go to your runserver window and you will be in an interactive IPython window.
I have a snippet set up in TextMate so I just type ipshell and hit tab. I couldn't live without it.
Solution 12 - Python
Run a development SMTP server that will just output whatever is sent to it (if you don't want to actually install SMTP on your dev server.)
command line:
python -m smtpd -n -c DebuggingServer localhost:1025
Solution 13 - Python
From the django-admin documentation:
If you use the Bash shell, consider installing the Django bash completion script, which lives in extras/django_bash_completion
in the Django distribution. It enables tab-completion of django-admin.py
and manage.py
commands, so you can, for instance...
-
Type
django-admin.py
. -
Press [TAB] to see all available options.
-
Type
sql
, then [TAB], to see all available options whose names start withsql
.
Solution 14 - Python
The ./manage.py runserver_plus
facilty which comes with django_extensions is truly awesome.
It creates an enhanced debug page that, amongst other things, uses the Werkzeug debugger to create interactive debugging consoles for each point in the stack (see screenshot). It also provides a very useful convenience debugging method dump()
for displaying information about an object/frame.
To install, you can use pip:
pip install django_extensions
pip install Werkzeug
Then add 'django_extensions'
to your INSTALLED_APPS
tuple in settings.py
and start the development server with the new extension:
./manage.py runserver_plus
This will change the way you debug.
Solution 15 - Python
I like to use the Python debugger pdb to debug Django projects.
This is a helpful link for learning how to use it: http://www.ferg.org/papers/debugging_in_python.html
Solution 16 - Python
When trying to exchange data between Django and another application, request.raw_post_data
is a good friend. Use it to receive and custom-process, say, XML data.
Documentation: http://docs.djangoproject.com/en/dev/ref/request-response/
Solution 17 - Python
Use Jinja2 alongside Django.
If you find the Django template language extremely restricting (like me!) then you don't have to be stuck with it. Django is flexible, and the template language is loosely coupled to the rest of the system, so just plug-in another template language and use it to render your http responses!
I use Jinja2, it's almost like a powered-up version of the django template language, it uses the same syntax, and allows you to use expressions in if statements! no more making a custom if-tags such as if_item_in_list
! you can simply say %{ if item in list %}
, or {% if object.field < 10 %}
.
But that's not all; it has many more features to ease template creation, that I can't go though all of them in here.
Solution 18 - Python
Add assert False
in your view code to dump debug information.
Solution 19 - Python
This adds to the reply above about Django URL names and reverse URL dispatching.
The URL names can also be effectively used within templates. For example, for a given URL pattern:
url(r'(?P<project_id>\d+)/team/$', 'project_team', name='project_team')
you can have the following in templates:
<a href="{% url project_team project.id %}">Team</a>
Solution 20 - Python
Since Django "views" only need to be callables that return an HttpResponse, you can easily create class-based views like those in Ruby on Rails and other frameworks.
There are several ways to create class-based views, here's my favorite:
from django import http
class RestView(object):
methods = ('GET', 'HEAD')
@classmethod
def dispatch(cls, request, *args, **kwargs):
resource = cls()
if request.method.lower() not in (method.lower() for method in resource.methods):
return http.HttpResponseNotAllowed(resource.methods)
try:
method = getattr(resource, request.method.lower())
except AttributeError:
raise Exception("View method `%s` does not exist." % request.method.lower())
if not callable(method):
raise Exception("View method `%s` is not callable." % request.method.lower())
return method(request, *args, **kwargs)
def get(self, request, *args, **kwargs):
return http.HttpResponse()
def head(self, request, *args, **kwargs):
response = self.get(request, *args, **kwargs)
response.content = ''
return response
You can add all sorts of other stuff like conditional request handling and authorization in your base view.
Once you've got your views setup your urls.py will look something like this:
from django.conf.urls.defaults import *
from views import MyRestView
urlpatterns = patterns('',
(r'^restview/', MyRestView.dispatch),
)
Solution 21 - Python
Instead of using render_to_response
to bind your context to a template and render it (which is what the Django docs usually show) use the generic view direct_to_template
. It does the same thing that render_to_response
does but it also automatically adds RequestContext to the template context, implicitly allowing context processors to be used. You can do this manually using render_to_response
, but why bother? It's just another step to remember and another LOC. Besides making use of context processors, having RequestContext in your template allows you to do things like:
<a href="{{MEDIA_URL}}images/frog.jpg">A frog</a>
which is very useful. In fact, +1 on generic views in general. The Django docs mostly show them as shortcuts for not even having a views.py file for simple apps, but you can also use them inside your own view functions:
from django.views.generic import simple
def article_detail(request, slug=None):
article = get_object_or_404(Article, slug=slug)
return simple.direct_to_template(request,
template="articles/article_detail.html",
extra_context={'article': article}
)
Solution 22 - Python
I don't have enough reputation to reply to the comment in question, but it's important to note that if you're going to use Jinja, it does NOT support the '-' character in template block names, while Django does. This caused me a lot of problems and wasted time trying to track down the very obscure error message it generated.
Solution 23 - Python
django.db.models.get_model
does allow you to retrieve a model without importing it.
James shows how handy it can be: "Django tips: Write better template tags — Iteration 4 ".
Solution 24 - Python
The webdesign app is very useful when starting to design your website. Once imported, you can add this to generate sample text:
{% load webdesign %}
{% lorem 5 p %}
Solution 25 - Python
Everybody knows there is a development server you can run with "manage.py runserver", but did you know that there is a development view for serving static files (CSS / JS / IMG) as well ?
Newcomers are always puzzled because Django doesn't come with any way to serve static files. This is because the dev team think it is the job for a real life Web server.
But when developing, you may not want to set up Apache + mod_wisgi, it's heavy. Then you can just add the following to urls.py:
(r'^site_media/(?P<path>.*)$', 'django.views.static.serve',
{'document_root': '/path/to/media'}),
Your CSS / JS / IMG will be available at www.yoursite.com/site_media/.
Of course, don't use it in a production environment.
Solution 26 - Python
I learned this one from the documentation for the sorl-thumbnails app. You can use the "as" keyword in template tags to use the results of the call elsewhere in your template.
For example:
{% url image-processor uid as img_src %}
<img src="{% thumbnail img_src 100x100 %}"/>
This is mentioned in passing in the Django templatetag documentation, but in reference to loops only. They don't call out that you can use this elsewhere (anywhere?) as well.
Solution 27 - Python
django.views.generic.list_detail.object_list -- It provides all the logic & template variables for pagination (one of those I've-written-that-a-thousand-times-now drudgeries). Wrapping it allows for any logic you need. This gem has saved me many hours of debugging off-by-one errors in my "Search Results" pages and makes the view code cleaner in the process.
Solution 28 - Python
PyCharm IDE is a nice environment to code and especially debug, with built-in support for Django.
Solution 29 - Python
Use xml_models to create Django models that use an XML REST API backend (instead of a SQL one). This is very useful especially when modelling third party APIs - you get all the same QuerySet syntax that you're used to. You can install it from PyPI.
XML from an API:
<profile id=4>
<email>[email protected]</email>
<first_name>Joe</first_name>
<last_name>Example</last_name>
<date_of_birth>1975-05-15</date_of_birth>
</profile>
And now in python:
class Profile(xml_models.Model):
user_id = xml_models.IntField(xpath='/profile/@id')
email = xml_models.CharField(xpath='/profile/email')
first = xml_models.CharField(xpath='/profile/first_name')
last = xml_models.CharField(xpath='/profile/last_name')
birthday = xml_models.DateField(xpath='/profile/date_of_birth')
finders = {
(user_id,): settings.API_URL +'/api/v1/profile/userid/%s',
(email,): settings.API_URL +'/api/v1/profile/email/%s',
}
profile = Profile.objects.get(user_id=4)
print profile.email
# would print '[email protected]'
It can also handle relationships and collections. We use it every day in heavily used production code, so even though it's beta it's very usable. It also has a good set of stubs that you can use in your tests.
(Disclaimer: while I'm not the author of this library, I am now a committer, having made a few minor commits)
Solution 30 - Python
Use database migrations. Use South.
Solution 31 - Python
Just found this link: http://lincolnloop.com/django-best-practices/#table-of-contents - "Django Best Practices".
Solution 32 - Python
Instead of evaluating whole queryset to check whether you got back any results, use .exists() in Django 1.2+ and .count() for previous versions.
Both exists() and count() clears order by clauses and retrieves a single integer from DB. However exists() will always return 1 where as count may return higher values on which limits will be applied manually. Source for has_result used in exists() and get_count used in count() for the curious.
Since they both return a single integer, there's no model instantiation, loading model attributes in memory and no large TextFields being passed between your DB and app.
If you have already evaluated the query, .count() computes len(cached_result) and .exists() computes bool(cached_result)
Not efficient - Example 1
books = Books.objects.filter(author__last_name='Brown')
if books:
# Do something
Not efficient - Example 2
books = Books.objects.filter(author__last_name='Brown')
if len(books):
# Do something
Efficient - Example 1
books = Books.objects.filter(author__last_name='Brown')
if books.count():
# Do something
Efficient - Example 2
books = Books.objects.filter(author__last_name='Brown')
if books.exists():
# Do something
Solution 33 - Python
If you make changes into model
./manage.py dumpdata appname > appname_data.json
./manage.py reset appname
django-admin.py loaddata appname_data.json
Solution 34 - Python
Use signals to add accessor-methods on-the-fly.
I saw this technique in django-photologue: For any Size object added, the post_init signal will add the corresponding methods to the Image model.
If you add a site giant, the methods to retrieve the picture in giant resolution will be image.get_giant_url()
.
The methods are generated by calling add_accessor_methods
from the post_init
signal:
def add_accessor_methods(self, *args, **kwargs):
for size in PhotoSizeCache().sizes.keys():
setattr(self, 'get_%s_size' % size,
curry(self._get_SIZE_size, size=size))
setattr(self, 'get_%s_photosize' % size,
curry(self._get_SIZE_photosize, size=size))
setattr(self, 'get_%s_url' % size,
curry(self._get_SIZE_url, size=size))
setattr(self, 'get_%s_filename' % size,
curry(self._get_SIZE_filename, size=size))
See the source code of photologue.models for real-world usage.
Solution 35 - Python
Remove Database Access Information from settings.py
One thing I've done in my Django site's settings.py
is load database access info from a file in /etc
. This way the access setup (database host, port, username, password) can be different for each machine, and sensitive info like the password isn't in my project's repository. You might want to restrict access to the workers in a similar manner, by making them connect with a different username.
You could also pass in the database connection information, or even just a key or path to a configuration file, via environment variables, and handle it in settings.py
.
For example, here's how I pull in my database configuration file:
g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
DATABASES = dbSetup['databases']
else:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
# ...
}
}
Needless to say, you need to make sure that the file in DB_CONFIG
is not accessible to any user besides the db admins and Django itself. The default case should refer Django to a developer's own test database. There may also be a better solution using the ast
module instead of execfile
, but I haven't researched it yet.
Another thing I do is use separate users for DB admin tasks vs. everything else. In my manage.py
, I added the following preamble:
# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
and goodFile(adminDBConfFile):
os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
os.environ['DB_CONFIG'] = dbConfFile
Where the config in /etc/django/db_regular.py
is for a user with access to only the Django database with SELECT, INSERT, UPDATE, and DELETE, and /etc/django/db_admin.py
is for a user with these permissions plus CREATE, DROP, INDEX, ALTER, and LOCK TABLES. (The migrate
command is from South.) This gives me some protection from Django code messing with my schema at runtime, and it limits the damage an SQL injection attack can cause (though you should still check and filter all user input).
(Copied from my answer to another question)
Solution 36 - Python
Instead of running the Django dev server on localhost, run it on a proper network interface. For example:
python manage.py runserver 192.168.1.110:8000
or
python manage.py runserver 0.0.0.0:8000
Then you can not only easily use Fiddler (http://www.fiddler2.com/fiddler2/) or another tool like HTTP Debugger (http://www.httpdebugger.com/) to inspect your HTTP headers, but you can also access your dev site from other machines on your LAN to test.
Make sure you are protected by a firewall though, although the dev server is minimal and relatively safe.
Solution 37 - Python
Use wraps
decorator in custom views decorators to preserve view's name, module and docstring. E.g.
try:
from functools import wraps
except ImportError:
from django.utils.functional import wraps # Python 2.3, 2.4 fallback.
def view_decorator(fun):
@wraps(fun)
def wrapper():
# here goes your decorator's code
return wrapper
Beware: will not work on a class-based views (those with __call__
method definition), if the author hasn't defined a __name__
property. As a workaround use:
from django.utils.decorators import available_attrs
...
@wraps(fun, assigned=available_attrs(fun))
Solution 38 - Python
The Django Debug Toolbar is really fantastic. Not really a toolbar, it actually brings up a sidepane that tells you all sorts of information about what brought you the page you're looking at - DB queries, the context variables sent to the template, signals, and more.
Solution 39 - Python
Using an 'apps' folder to organize your applications without editing PYTHONPATH
This has come handy when I want to organize my folders like this:
apps/
foo/
bar/
site/
settings.py
urls.py
without overwritting PYTHONPATH or having to add apps to every import like:
from apps.foo.model import *
from apps.bar.forms import *
In your settings.py add
import os
import sys
PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
sys.path.insert(0, os.path.join(PROJECT_ROOT, "apps"))
and you are ready to go :-)
I saw this at http://codespatter.com/2009/04/10/how-to-add-locations-to-python-path-for-reusable-django-apps/
Solution 40 - Python
Render form via django template instead of as_(ul|table|p)().
This article shows, how to use template to render CusstomForms instead of as_p()
, as_table()
...
To make it work change
-
from django import newforms as forms
tofrom django import forms
-
from django.newforms.forms import BoundField
tofrom django.forms.forms import BoundField
Solution 41 - Python
Use djangorecipe to manage your project
- If you're writing a new app, this recipe makes testing it outside of a project really easy
- It allows you to manage dependencies for a project (e.g. what version of some app it should depend on)
All you have to do to get started is this:
-
Create a folder for your new website (or library)
-
Create a buildout.cfg with following content in it:
[buildout] parts=django [django] recipe=djangorecipe version=1.1.1 project=my_new_site settings=development
[django] recipe=djangorecipe version=1.1.1 project=my_new_site settings=development
-
Grab a bootstrap.py to get a local installation of buildout and place it within your directory. You can either go with the official one (sorry, Markdown didn't like part of the full link :-/ ) or with one that uses distribute instead of setuptools as described by Reinout van Rees.
-
python bootstrap.py
(orpython bootstrap_dev.py
if you want to use distribute). -
./bin/buildout
That's it. You should now have a new folder "my_new_site", which is your new django 1.1.1 project, and in ./bin you will find the django
-script which replaces the manage.py on a normal installation.
What's the benefit? Let's say you want to use something like django-comment-spamfighter in your project. All you'd have to do is change your buildout.cfg to something like this:
[buildout]
parts=django
[django]
recipe=djangorecipe
version=1.1.1
project=my_new_site
settings=development
eggs=
django-comments-spamfighter==0.4
[django]
recipe=djangorecipe
version=1.1.1
project=my_new_site
settings=development
eggs=
django-comments-spamfighter==0.4
Note that all I did was to add the last 2 lines which say, that the django-part should also have the django-comments-spamfighter package in version 0.4. The next time you run ./bin/buildout
, buildout will download that package and modify ./bin/django to add it to its PYTHONPATH.
djangorecipe is also suited for deploying your project with mod_wsgi. Just add the wsgi=true
setting to the django-part of your buildout.cfg and a "django.wsgi" will appear in your ./bin folder :-)
And if you set the test
option to a list of applications, the djangorecipe will create a nice wrapper for you that runs all the tests for the listed application in your project.
If you want to develop a single app in a standalone environment for debugging etc., Jakob Kaplan-Moss has a quite complete tutorial on his blog
Solution 42 - Python
Use reverse in your urlconf.
This is one of those tricks where I don't understand why it isn't the default.
Here's a link to where I picked it up: http://andr.in/2009/11/21/calling-reverse-in-django/
Here's the code snippet:
from django.conf.urls.defaults import *
from django.core.urlresolvers import reverse
from django.utils.functional import lazy
from django.http import HttpResponse
reverse_lazy = lazy(reverse, str)
urlpatterns = patterns('',
url(r'^comehere/', lambda request: HttpResponse('Welcome!'), name='comehere'),
url(r'^$', 'django.views.generic.simple.redirect_to',
{'url': reverse_lazy('comehere')}, name='root')
)
urlpatterns = patterns('',
url(r'^comehere/', lambda request: HttpResponse('Welcome!'), name='comehere'),
url(r'^$', 'django.views.generic.simple.redirect_to',
{'url': reverse_lazy('comehere')}, name='root')
)
Solution 43 - Python
Automatically set 'DEBUG' attribute on production environment (settings.py)
import socket
if socket.gethostname() == 'productionserver.com':
DEBUG = False
else:
DEBUG = True
Solution 44 - Python
This is a really easy way to never have to import another one of your models again in your python shell.
First, install IPython (If you don't use IPython, what's wrong with you?). Next, create a python script, ipythonrc.py, in your django project directory with the following code in it:
from django.db.models.loading import get_models
for m in get_models():
globals()[m.__name__] = m
#NOTE: if you have two models with the same name you'll only end up with one of them
Then, in your ~/.ipython/ipythonrc file, put the following code in the "Python files to load and execute" section:
execfile /path/to/project/ipythonrc.py
Now every time you start up IPython or run ./manage.py shell
you will have all your models already imported and ready to use. No need to ever import another model again.
You can also put any other code you execute a lot in your ipythonrc.py file to save yourself time.
Solution 45 - Python
Changing Django form field properties on init
Sometimes it's useful to pass extra arguments to a Form class.
from django import forms
from mymodels import Group
class MyForm(forms.Form):
group=forms.ModelChoiceField(queryset=None)
email=forms.EmailField()
some_choices=forms.ChoiceField()
def __init__(self,my_var,*args,**kwrds):
super(MyForm,self).__init__(*args,**kwrds)
self.fields['group'].queryset=Group.objects.filter(...)
self.fields['email'].widget.attrs['size']='50'
self.fields['some_choices']=[[x,x] for x in list_of_stuff]
source: Dzone snippets
Solution 46 - Python
django_extensions
from https://github.com/django-extensions/django-extensions is just great.
Few nice ./manage.py
commands:
shell_plus
- autoimports models from all INSTALLED_APPSshow_urls
- prints all urls defined in all apps in projectrunscript
- runs any script in project context (you can use models and other Django-related modules)
Solution 47 - Python
PyCharm and Wingware IDE is great tool if you have money to pay for the license.
Solution 48 - Python
Use isapi-wsgi and django-pyodbc to run Django on Windows using IIS and SQL Server!
Solution 49 - Python
Create dynamic models for sets of legacy tables with the same structure:
class BaseStructure(models.Model):
name = models.CharField(max_length=100)
address = models.CharField(max_length=100)
class Meta:
abstract=True
class DynamicTable(models.Model):
table_name = models.CharField(max_length=20)
def get_model(self):
class Meta:
managed=False
table_name=self.table_name
attrs = {}
attrs['Meta'] = Meta
# type(new_class_name, (base,classes), {extra: attributes})
dynamic_class = type(self.table_name, (BaseStructure,), attrs)
return dynamic_class
customers = DynamicTable.objects.get(table_name='Customers').get_model()
me = customers.objects.get(name='Josh Smeaton')
me.address = 'Over the rainbow'
me.save()
This assumes that you have legacy tables with the same structure. Instead of creating a model to wrap each of the tables, you define one base model, and dynamically construct the class needed to interact with a specific table.
Solution 50 - Python
A bit late to the party. But Django Canvas has recently come out and it deserves a place here.
Don't start your project with django-admin.py startproject
. Instead you can use something like Django Canvas to help piece together a blank project with the modules you need.
You go to that site, tick some options and then download a blank project, so simple.
It has all the common things like South schema migrations and Command Extensions as well as a lot of other best practices mentioned here. Plus it has a great start.sh/shart.bat
script that will install python, virtualenv, pip, django and whatever you need to start from a fresh copy of windows, osx or linux.
Solution 51 - Python
Use asynchronous tasks. Use Celery
Solution 52 - Python
Read Unbreaking Django if you haven't already. It contains lots of useful information regarding django pitfalls.
Solution 53 - Python
When passing variables from a view to a template the response dictionary can become tedious to type out. I find it nice to just pass all the local variables at once using locals()
.
def show_thing(request, thing_id):
thing = Thing.objects.get(pk=thing_id)
return render_to_response('templates/things/show.html', locals())
(Not a hidden feature per se but nevertheless helpful when new to Python and or Django.)
Edit: Obviously it's better to be explicit than implicit but this approach can be helpful during development.
Solution 54 - Python
dir() & raise ValueError()
For debugging / exploring the state of things during development, I use the following trick:
...
to_see = dir(inspect_this_thing)
to_see2 = inspect_this_thing.some_attribute
raise ValueError("Debugging")
...
This is especially helpful when you're working on parts of django that aren't particularly well documented (form.changed_fields is one I used this on recently).
locals().
Instead of writing out every variable for the template context, use the python builtin locals() command which creates a dictionary for you:
#This is tedious and not very DRY
return render_to_response('template.html', {"var1": var1, "var2":var2}, context_instance=RequestContext(request))
#95% of the time this works perfectly
return render_to_response('template.html', locals(), context_instance=RequestContext(request))
#The other 4.99%
render_dict = locals()
render_dict['also_needs'] = "this value"
return render_to_response('template.html', render_dict, context_instance=RequestContext(request))
Solution 55 - Python
Django hasn't got app settings, so i made my own app_settings.py detection. At the bottom of the settings.py i added this code:
import sys, os
# Append application settings without triggering the __init__.
for installed_app in INSTALLED_APPS:
# Ignore django applications
if not installed_app.startswith('django.'):
# Find the app (and the settings file)
for path in sys.path:
path = os.path.join(path, installed_app, 'app_settings.py')
if os.path.isfile(path):
# Application settings found
exec open(path).read()
It detects app_settings.py in all the INSTALLED_APPS. Instead of importing it, it will read the contents of the app_settings file and will execute it inline. If app_settings is imported directly all sort of Django import errors will be raised (because Django isn't initialized yet).
So my app/app_settings.py will look like this:
MIDDLEWARE_CLASSES += (
'app.middleware.FancyMiddleware',
)
Now the application only has to be added to the INSTALLED_APPS, instead of finding all application settings and add them to the settings.py (middleware, urls...)
Note: It would be better if Django had a hook to append extra settings, so application settings could be added on startup (or in runtime).