Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
uWSGI reaches the 0.9.3 Milestone
uWSGI project [1] reaches the 0.9.3 milestone. You can review the complete announcement [2] on the mailing list and download the code here [3]This new release brings some new exiting features :- Nginx 0.7.x module- configuration via python module- support (non-standard) for Python 3.x- Twisted client resource adapter- graceful restart of worker processes and hot-plug substitution/upgradeof the uWSGI server- shared memory area to share data between workers/processes- Tomcat handler- support for virtualenvIn this post [4] I have covered the usage of both the "configuration via a python module" and the "virtualenv support".uWSGI allows you to run your favorite wsgi application on top of prefered web server (apache, cherokee or nginx).[1] http://projects.unbit.it/uwsgi/[2] http://lists.unbit.it/pipermail/uwsgi/2009-November/000020.html[3] http://projects.unbit.it/downloads/uwsgi-0.9.3.tar.gz[4] http://yml-blog.blogspot.com/2009/11/setting-up-django-project-with-cherokee.html -
8 Books To Get A Developer For The Holidays
Send this to your significant other/parent/relative/friend so, instead of that sweater, you get one of these nuggets of awesome this Christmas. The Pragmatic Programmer: From Journeyman to Master Write better, cleaner, more maintainable code. Learn how to manage your projects and focus on shipping your product. With insight that covers the gamut of software development [...] Related posts:Be Language Agnostic – Solve the Problem! Deployment Using Capistrano / Webistrano via Rails / Phusion Passenger Django 1.0 Template Development: Sample Chapter “Serving Multiple Templates” -
Should you go with Google App Engine?
Recently I responded to the question on Stack Overflow about wether Google App Engine is worth it, over conventional hosting providers for typical databased-backed setup. I will not recite all the pros and cons of App Engine as I already did that in my answer, but I would like to focus on one interesting aspect of Google App Engine where it wins big time over conventional hosting approaches. In particular - the deployment process. Let's get started... Deploying on regular hosting environment How do you deploy a web application (like Django for example) to an Apache-backed hosting server? Well there are a few steps you have to take: FTP or SCP your applicaton to the server Replace the folder with the new folder Stop the server, services etc.. Start the server services etc... BONUS: Modify your databse schema Of course if you are proper developer you might simplify you deployment process and also make use of revision control system. You can also write a script to automate the deployment process, in particular for steps 3-5: Commit your code to revision control, possibly marking it with a tag for Release or Deployment. Log onto your producton server Check out the code … -
You Built a Metaclass for *what*?
Recently I had a bit of an interesting problem, I needed to define a way to represent a C++ API in Python. So, I figured the best way to represent that was one class in Python for each class in C++, with a functions dictionary to track each of the methods on each class. Seems simple enough right, do something like this: class String(object): functions = { "size": Function(Integer, []), }We've got a String class with a functions dictionary that maps method names to Function objects. The Function constructor takes a return type and a list of arguments. Unfortunately we run into a problem when we want to do something like this: class String(object): functions = { "size": Function(Integer, []), "append": Function(None, [String]) }If we try to run this code we're going to get a NameError, String isn't defined yet. Django models have a similar issue, with recursive foreign keys. Django's solution is to use the placeholder string "self", and have a metaclass translate it into the right class. Also having a slightly more declarative API might be nice, so something like this: class String(DeclarativeObject): size = Function(Integer, []) append = Function(None, ["self"])So now that we have a nice pretty … -
Getting Started with Testing in Django
Following yesterday's post another hotly requested topic was testing in Django. Today I wanted to give a simple overview on how to get started writing tests for your Django applications. Since Django 1.1, Django has automatically provided a tests.py file when you create a new application, that's where we'll start.For me the first thing I want to test with my applications is, "Do the views work?". This makes sense, the views are what the user sees, they need to at least be in a working state (200 OK response) before anything else can happen (business logic). So the most basic thing you can do to start testing is something like this: from django.tests import TestCase class MyTests(TestCase): def test_views(self): response = self.client.get("/my/url/") self.assertEqual(response.status_code, 200)By just making sure you run this code before you commit something you've already eliminated a bunch of errors, syntax errors in your URLs or views, typos, forgotten imports, etc. The next thing I like to test is making sure that all the branches of my code are covered, the most common place my views have branches is in views that handle forms, one branch for GET and one for POST. So I'll write a test like … -
Django and Python 3
Today I'm starting off doing some of the posts people want to see, and the number one item on that list is Django and Python 3. Python 3 has been out for about a year at this point, and so far Django hasn't really started to move towards it (at least at a first glance). However, Django has already begun the long process towards moving to Python 3, this post is going to recap exactly what Django's migration strategy is (most of this post is a recap of a message James Bennett sent to the django-developers mailing list after the 1.0 release, available here).One of the most important things to recognize in this that though there are many developers using Django for smaller projects, or new projects that want to start these on Python 3, there are also a great many more with legacy (as if we can call recent deployments on Python2.6 and Django 1.1 legacy) deployments that they want to maintain and update. Further, Django's latest release, 1.1, has support for Python releases as old as 2.3, and a migration to Python 3 from 2.3 is nontrivial. However, it is significantly easier to make this migration from Python … -
Why Meta.using was removed
Recently Russell Keith-Magee and I decided that the Meta.using option needed to be removed from the multiple-db work on Django, and so we did. Yesterday someone tweeted that this change caught them off guard, so I wanted to provide a bit of explanation as to why we made that change.The first thing to note is that Meta.using was very good for one specific use case, horizontal partitioning by model. Meta.using allowed you to tie a specific model to a specific database by default. This meant that if you wanted to do things like have users be in one db and votes in another this was basically trivial. Making this use case this simple was definitely a good thing.The downside was that this solution was very poorly designed, particularly in light on Django's reusable application philosophy. Django emphasizes the reusability of application, and having the Meta.using option tied your partitioning logic to your models, it also meant that if you wanted to partition a reusable application onto another DB this easily the solution was to go in and edit the source for the reusable application. Because of this we had to go in search of a better solution.The better solution we've … -
Splitting up Django models
Sometimes it makes sense to split up your Django models for a specific application across multiple files instead of having all of them in one models.py file. This allows for easier and simpler code organization and maintenance. Splitting up your models in Django is fairly simple, although it requires a few extra steps. In our example, [...] -
Django for a Rails Developer
This is not yet another Django vs Rails blog post. It is a compilation of notes I made working with Django after having worked on Rails for years. In this post I want to give a brief introduction to Django project layout from a Rails developer point of view, on what is there, what is [...] Related posts:Rails and Django commands : comparison and conversion The Rails and Django models layer Rosseta stone Tools of Pro Django developer – aka What powers dinette and almost every app we write. -
Filing a Good Ticket
I read just about every single ticket that's filed in Django's trac, and at this point I'e gotten a pretty good sense of what (subjectively) makes a useful ticket. Specifically there are a few things that can make your ticket no better than spam, and a few that can instantly bump your ticket to the top of my "TODO" list. Hopefully, these will be helpful in both filing ticket's for Django as well as other open source projects.Search for a ticket before filing a new one. Django's trac, for example, has at least 10 tickets describing "Decoupling urls in the tutorial, part 3". These have all been wontfixed (or closed as a duplicate of one of the others). Each time one of these is filed it takes time for someone to read through it, write up an appropriate closing message, and close it. Of course, the creator of the ticket also invested time in filing the ticket. Unfortunately, for both parties this is time that could be better spent doing just about anything else, as the ticket has been decisively dealt with plenty of times.On a related note, please don't reopen a ticket that's been closed before. This one depends … -
Javascript inline forms outside of contrib.admin
This recipe follows on from the last two and shows how to do the addition of inline fields to a model form, outside of contrib.admin. -
What apps do I use?
I've been asked by a few people what apps am I going to use for this website. I'll probably go into some of them in a bit more detail at some point. However, I thought for those that are interested I would quickly dump my pip requirements.txt here. Django==1.1.1 Markdown==2.0.3 MySQL-python==1.2.3c1 #PIL==1.1.6 Pygments==0.10 South==0.6.2 Sphinx==0.5.2 django-tagging==0.3 docutils==0.5 oauth==1.0.1 simplejson==2.0.9 sorl-thumbnail==3.2.5 textile==2.1.3 twisted wsgiref==0.1.2 html5lib==0.11.1 pisa==3.0.32 django-debug-toolbar==0.8.1 django-vcs==0.1 django-disqus==0.2 http://effbot.org/downloads/Imaging-1.1.6.tar.gz http://www.reportlab.org/ftp/ReportLab_2_3.tar.gz -e git+git://github.com/dustin/twitty-twister.git#egg=twittywtister -e git+git://github.com/montylounge/django-basic-apps.git#egg=basic That gives you quite a good idea about what I'm using. It also maybe gives away some of the features I'm planning... well, a hint or two perhaps! -
A Bit of Benchmarking
PyPy recently posted some interesting benchmarks from the computer language shootout, and in my last post about Unladen Swallow I described a patch that would hopefully be landing soon. I decided it would be interesting to benchmarks something with this patch. For this I used James Tauber's Mandelbulb application, at both 100x100 and 200x200. I tested CPython, Unladen Swallow Trunk, Unladen Swallow Trunk with the patch, and a recent PyPy trunk (compiled with the JIT). My results were as follows:100CPython 2.6.4 17sUnladen Swallow Trunk 16sUnladen Swallow Trunk + Patch 13sPyPy Trunk 10s200CPython 2.6.4 64sUnladen Swallow Trunk 52sUnladen Swallow Trunk + Patch 49sPyPy 46sInteresting results. At 100x100 PyPy smokes everything else, and the patch shows a clear benefit for Unladen. However, at 200x200 both PyPy and the patch show diminishing returns. I'm not clear on why this is, but my guess is that something about the increased size causes a change in the parameters that makes the generated code less efficient for some reason.It's important to note that Unladen Swallow has been far less focussed on numeric benchmarks than PyPy, instead focusing on more web app concerns (like template languages). I plan to benchmark some of these as time goes on, … -
Writing your own template loaders
Django has three builtin template loaders which are used to get the templates for rendering. TEMPLATE_LOADERS = ( 'django.template.loaders.filesystem.load_template_source', 'django.template.loaders.app_directories.load_template_source', # 'django.template.loaders.eggs.load_template_source', ) Writing your template loader is a awfuly easy. It is a callable which Returns a tuple of (openfile, filename) if it can find the template. Raise TemplateDoesNotExist if the templates cannot be [...] Related posts:A response to Dropping Django -
Things College Taught me that the "Real World" Didn't
A while ago Eric Holscher blogged about things he didn't learn in college. I'm going to take a different spin on it, looking at both things that I did learn in school that I wouldn't have learned else where (henceforth defined as my job, or open source programming), as well as thinks I learned else where instead of at college.Things I learned in college:Big O notation, and algorithm analysis. This is the biggest one, I've had little cause to consider this in my open source or professional work, stuff is either fast or slow and that's usually enough. Learning rigorous algorithm analysis doesn't come up all the time, but every once in a while it pops up, and it's handy.C++. I imagine that I eventually would have learned it myself, but my impetus to learn it was that's what was used for my CS2 class, so I started learning with the class then dove in head first. Left to my own devices I may very well have stayed in Python/Javascript land.Finite automaton and push down automaton. I actually did lexing and parsing before I ever started looking at these in class (see my blog posts from a year ago) using … -
Another Pair of Unladen Swallow Optimizations
Today a patch of mine was committed to Unladen Swallow. In the past weeks I've described some of the optimizations that have gone into Unladen Swallow, in specific I looked at removing the allocation of an argument tuple for C functions. One of the "on the horizon" things I mentioned was extending this to functions with a variable arity (that is the number of arguments they take can change). This has been implemented for functions that take a finite range of argument numbers (that is, they don't take *args, they just have a few arguments with defaults). This support was used to optimize a number of builtin functions (dict.get, list.pop, getattr for example).However, there were still a number of functions that weren't updated for this support. I initially started porting any functions I saw, but it wasn't a totally mechanical translation so I decided to do a little profiling to better direct my efforts. I started by using the cProfile module to see what functions were called most frequently in Unladen Swallow's Django template benchmark. Imagine my surprise when I saw that unicode.encode was called over 300,000 times! A quick look at that function showed that it was a perfect … -
Announcing django-admin-histograms
This is just a quick post because it's already past midnight here. Last week I realized some potentially useful code that I extracted from the DjangoDose and typewar codebases. Basically this code let's you get simple histogram reports for models in the admin, grouped by a date field. After I released it David Cramer did some work to make the code slightly more flexible, and to provide a generic templatetag for creating these histograms anywhere. The code can be found on github, and if you're curious what it looks like there's a screenshot on the wiki. Enjoy. -
Continous sphinx build
I have always found the cycle : Edit the documentation source => build the sphinx based documentation [1] => open a browser pointing the updated documentation and re iterate until your are satisfied a bit painful.Today I have finally found an automated version of this workflow that gave me one of this nice WAHOUUUU feeling that happens after you remove this little stone from your shoe.The idea is to continuously build the documentation using watch [2]watch -n 2 make htlmThis will update the generated documentation every 2 seconds. This is nice in itself and it leads me to discover that Epiphany automatically reload the page when it changes.[1] http://sphinx.pocoo.org/[2] http://linux.die.net/man/1/watch[3] http://projects.gnome.org/epiphany/ -
Hooking into django's login and logout - two approaches
Hooking into django's authentication system using two approaches: a custom authentication_backend and signals. -
Запускаем progopedia.com
Запускаем англоязычную версию Прогопедии — свободной энциклопедии языков программирования — progopedia.com. Сайт еще в стадии альфа-версии, не хватает описаний многих популярных языков программирования, движок определенно требует доработки — но для начала неплохо, я думаю. Сайт использует Django (естественно), Markdown (при помощи http://pypi.python.org/pypi/Markdown/) в качестве языка разметки, Pygments для подсветки синтаксиса, django-reversion для контроля версий, DISQUS и django-disqus для комментариев. Отзывы и комментарии приветствуются. Кто хочет присоединиться к progopedia.com в качестве редактора — присоединяйтесь :-) -
My Next Blog
I've been using this Blogspot powered blog for over a year now, and it is starting to get a little long in the tooth. Therefore I've been planning on moving to a new, shinny, blog of my own in the coming months. Specifically it's going to be my goal to get myself 100% migrated over my winter break. Therefore I've started building myself a list of features I want:Able to migrate all my old posts. This isn't going to be a huge deal, but it has to happen as I have quite a few posts I don't want to lose.Accepts restructured text. I'm sick of writing my posts in reST and then converting it into HTML for Blogspot.Pretty code highlighting.Disqus for comments. I don't want to have to deal with spam or anything else, let users post with Disqus and they can deal with all the trouble.Looks decent. Design is a huge weak point for me, so most of my time is going to be dedicated to this I think.Django powered!That's my pony list thus far. There's a good bet I'll use django-mingus since I've hear such good things about it, but for now I'm just dreaming of being able … -
Adding Javascript to contrib.admin inline fields
This recipe follows on from the last by adding Javascript to the inline fields of a model in the contrib.admin. -
Changes afoot at Django-NYC
Recently Justin Lilly and I have taken up the day-to-day running of the Django-NYC users group to take some load off its original founders, Loren Davie and Kevin Fricovsky. Loren and Kevin have done a great job of getting the group off the ground and building a community around Django in NYC. Unfortunately, as with most user groups, running [...] -
South – incredible easy migrations for Django
I’ve been hacking away at a side project for the past three or four weeks – got myself to internal milestone #2 this weekend, for which I’m really pleased. The very tail end of this milestone was deploying the code … Continue reading → -
Setup Python 2.6.4, mod_wsgi 2.6, and Django 1.1.1 on CentOS 5.3 (cPanel)
This is an update to my previous how-to Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel). The biggest reason why I chose to go with Python 2.5 at the time was because the MySQL Python (MySQLdb) package didn't support Python 2.6. The 1.2.3c1 release does so that roadblock is lifted. The instructions [...] Related posts:Setup Python 2.5, mod_wsgi, and Django 1.0 on CentOS 5 (cPanel) Ruby On Rails and SliceHost Part 1: Initial Setup Getting Started with Django and Python – First Impressions
