Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
On Django And Migrations
For at least a year now, people have been suggesting to me that South should be in Django core.I've always resisted, for good reason - not only because of South's relative immaturity at the time, but also because forcing a single solution would, I think, not be a good thing in general. (South, admittedly, has a few design issues, but it's all about tradeoffs.) However, last week at djangocon.eu, I revealed, in rapid-fire English (apologies to non-native speakers for that, we're working on time dilation) my Grand Plan for the future of South and Django migrations in general, one that seems to have the approval of at least a few members of Django core. The proposal is not, as some expected, to put South completely into Django core; instead, South will be split into two parts. One, the part that implements database abstraction, dependency resolution, and history tracking, would be put into Django itself. The other part - autodetection, model freezing, and so forth, will remain as South. (If you'd like more in-depth details of the split, see my post to django-developers.) The idea behind this is simple - take the parts of South that nearly any migration solution would … -
Appending the request URL to SQL statements in Django
Appending the request URL to SQL statements in Django. A clever frame-walking monkey-patch which pulls the most recent HttpRequest object out of the Python stack and adds the current request.path to each SQL query as an SQL comment, so you can see it in debugging tools such as slow query logs and the PostgreSQL “select * from pg_stat_activity” query. -
On Django And Migrations
For at least a year now, people have been suggesting to me that South should be in Django core. I've always resisted, for good reason - not only because of South's relative immaturity at the time, but also because forcing a single solution would, I think, not be a good thing in general. (South, admittedly, has a few design issues, but it's all about tradeoffs.) However, last week at djangocon.eu, I revealed, in rapid-fire English (apologies to non-native speakers for that, we're working on time dilation) my Grand Plan for the future of South and Django migrations in general, one that seems to have the approval of at least a few members of Django core. The proposal is not, as some expected, to put South completely into Django core; instead, South will be split into two parts. One, the part that implements database abstraction, dependency resolution, and history tracking, would be put into Django itself. The other part - autodetection, model freezing, and so forth, will remain as South. (If you'd like more in-depth details of the split, see my post to django-developers.) The idea behind this is simple - take the parts of South that nearly any migration solution … -
Class-based views and thread safety
I previously wrote about a thread-safety bug I encountered in writing a middleware object. I recently found a very similar situation in a class-based view I was modifying, and thought it was worth writing up what the problem was and how I solved it. Interestingly, there's a discussion going on in Django-developers at the moment on class-based views which touches on many of the same issues. By 'class-based view', I mean that rather than just being a function which is called from urls.py when the URL matches its pattern, this was a class with a __call__ method. In theory, that should work in exactly the same way as a function view - to Python, functions and callable objects are pretty much the same thing. One of the reasons that the controller was written as a class was that it had multiple utility methods that were called during the rendering process. To make it easier to pass data between the methods, various things were set as instance variables - self.item_id, self.key, and so on. However, the urlpattern for this view was defined like this: (r'^(?P<key>)/((?P<page>[^/]+)/)?', FormController()), which meant that it was instantiated just once per process: when the urls are first … -
Class-based views and thread safety
I previously wrote about a thread-safety bug I encountered in writing a middleware object. I recently found a very similar situation in a class-based view I was modifying, and thought it was worth writing up what the problem was and how I solved it. Interestingly, there's a discussion going on in Django-developers at the moment on class-based views which touches on many of the same issues. By 'class-based view', I mean that rather than just being a function which is called from urls.py when the URL matches its pattern, this was a class with a __call__ method. In theory, that should work in exactly the same way as a function view - to Python, functions and callable objects are pretty much the same thing. One of the reasons that the controller was written as a class was that it had multiple utility methods that were called during the rendering process. To make it easier to pass data between the methods, various things were set as instance variables - self.item_id, self.key, and so on. However, the urlpattern for this view was defined like this: (r'^(?P<key>)/((?P<page>[^/]+)/)?', FormController()), which meant that it was instantiated just once per process: when the urls are first … -
django-mozilla-product-details, because short library names are for wimps
Today, we have released a new library to consume Mozilla product details as well as language details from Django projects. -
django-mozilla-product-details, because short library names are for wimps
Today, we have released a new library to consume Mozilla product details as well as language details from Django projects. -
django-boss
django-boss (via). Management commands are one of the few bits of Django that I still have to look up in the documentation whenever I write them. django-boss offers a smart alternative to regular management commands, based around decorators and taking the containing app as the first argument. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
An autop Django template filter
autop is a script that was first written for WordPress by Matt Mullenweg (the WordPress founder). All WordPress blog posts are filtered using wpautop() (unless you install an additional plug-in to disable the filter). The function was also ported to Drupal, and it's enabled by default when entering body text into Drupal nodes. As far as I'm aware, autop has never been ported to a language other than PHP. Until now. In the process of migrating this site from Drupal to Django, I was surprised to discover that not only Django, but also Python in general, lacks any linebreak filtering function (official or otherwise) that's anywhere near as intelligent as autop. The built-in Django linebreaks filter converts all single newlines to <br /> tags, and all double newlines to <p> tags, completely irrespective of HTML block elements such as <code> and <script>. This was a fairly major problem for me, as I was migrating a lot of old content over from Drupal, and that content was all formatted in autop style. Plus, I'm used to writing content in that way, and I'd like to continue writing content in that way, whether I'm in a PHP environment or not. Therefore, I've … -
An autop Django template filter
autop is a script that was first written for WordPress by Matt Mullenweg (the WordPress founder). All WordPress blog posts are filtered using wpautop() (unless you install an additional plug-in to disable the filter). The function was also ported to Drupal, and it's enabled by default when entering body text into Drupal nodes. As far as I'm aware, autop has never been ported to a language other than PHP. Until now. In the process of migrating this site from Drupal to Django, I was surprised to discover that not only Django, but also Python in general, lacks any linebreak filtering function (official or otherwise) that's anywhere near as intelligent as autop. The built-in Django linebreaks filter converts all single newlines to <br /> tags, and all double newlines to <p> tags, completely irrespective of HTML block elements such as <code> and <script>. This was a fairly major problem for me, as I was migrating a lot of old content over from Drupal, and that content was all formatted in autop style. Plus, I'm used to writing content in that way, and I'd like to continue writing content in that way, whether I'm in a PHP environment or not. Therefore, I've … -
Darrera setmana de juny
Aquesta setmana he tocat molt poca cosa de Python i Django, el projecte que ens consumeix gran part del temps és una feina gairebé de rellotgeria però no és un projecte Python. Tot i això he fet servir Django per al prototipat d'algunes part de l'aplicació. És molt més senzill i ràpid muntar un prototip i fer-hi feina que tractar amb l'aplicació real, per molt que tenguem varis entorns de proves. Estic revisant també els vídeos de la Djangocon Europe 2010. He vist el de Django a l'empresa, el dedicat a la testabilitat i el de GUnicorn. Aquest darrer m'ha agradat especialment ja que tenim plans per anar incorporant GUnicorn com a mètode de referència de desplegament d'aplicacions Django. En aquests moments estam fent servir CherryPy i la veritat és que funciona molt bé. Encara que la màxima és "si funciona no ho canviïs" GUnicorn és un sistema WSGI molt més orientat a la feina que CherryPy, amb possibilitat de gestionar connexions síncrones i asíncrones. Els benchmarks que hi posen Gunicorn un poc pitjor que altres sistemses WSGI, però per notar-ne la diferència hem de gestionar un lloc web amb moooltes visites. En aquests casos el que ens puguin dir … -
Separating Django Users
Soon, me and my friends Rob Golding, Ben Jenkinson and Rob Miles will begin with MyUni. MyUni is a response to the terrible systems in place at our university to find lecture information and to submit coursework. We are building MyUni in our favourite framework, Django. We have gone through three prototype iterations thus far [...] -
More django-articles Updates
I've spent a little more time lately adding new features to django-articles. There are two major additions in the latest release (2.0.0-pre2). Article attachments Article statuses That's right folks! You can finally attach files to your articles. This includes attachments to emails that you send, if you have the articles from email feature properly configured. To prove it, I'm going to attach a file to this article (which I'm posting via email). Next, I've decided that it's worth allowing the user to specify different statuses for their articles. One of the neat things about this feature is that if you are a super user, you're logged in, and you save an article with a status that is designated as "non-live", you will still be able to see it on the site. This is a way for users to preview their work before making it live. Out of the box, there are only two statuses: draft and finished. You're free to add more statuses if you feel so inclined (they're in the database, not hardcoded). The article status is still separate from the "is_active" flag when saving an article. Any article that is marked as inactive will not appear on the … -
Deployment Using Fabric
Yesterday just a night before EuroDjangoCon 2010, I was writing deployment scripts for my personal project. I have been using analogous scripts at least for a year for my work projects of different scopes. And I can prove that it's really worth to have such scripts, because they save a lot of time and let you avoid confusion and mistakes. Most of the projects are continuously improved, so the main purpose of deployment in my case is not the initial installation, but handy and fast updating. For each website that I am managing, there are two environments set up under different domains, where one of them is production environment and another one is staging/testing environment. The configuration of staging environment mirrors the production environment. Both have their own webserver configurations, codebases, databases, and uploaded media files. At first the newest features are tested in the staging environment with the copy of live data, and then they are published in the production environment. I am using subversion for version control with third-party modules defined as svn:externals and put under the same codebase. Unfortunately, some of the modules have to be copied if they were originally taken from Git, Bazaar, or other … -
More django-articles Updates
I've spent a little more time lately adding new features to django-articles. There are two major additions in the latest release (2.0.0-pre2). Article attachments Article statuses That's right folks! You can finally attach files to your articles. This includes attachments to emails that you send, if you have the articles from email feature properly configured. To prove it, I'm going to attach a file to this article (which I'm posting via email). Next, I've decided that it's worth allowing the user to specify different statuses for their articles. One of the neat things about this feature is that if you are a super user, you're logged in, and you save an article with a status that is designated as "non-live", you will still be able to see it on the site. This is a way for users to preview their work before making it live. Out of the box, there are only two statuses: draft and finished. You're free to add more statuses if you feel so inclined (they're in the database, not hardcoded). The article status is still separate from the "is_active" flag when saving an article. Any article that is marked as inactive will not appear on the … -
Snippet: Django Columns Filter
I was looking around for an easy way to split lists of items into columns in a way that the number of items in each column would be less than or equal to the number of items in the first column. This prevents a final column with several more items than the others. I came across an old post from Annie Mullin that established a templatetag to do this using a generator. I liked the idea, but felt that a templatetag was too unwieldy - a filter would be simpler and easier to use in a template. So, I turned it into one: @register.filter def columns(lst, cols): """ Break a list into ``n`` lists, typically for use in columns. >>> lst = range(10) >>> for list in columns(lst, 3): ... list [0, 1, 2, 3] [4, 5, 6] [7, 8, 9] """ try: cols = int(cols) lst = list(lst) except (ValueError, TypeError): raise StopIteration() start = 0 for i in xrange(cols): stop = start + len(lst[i::cols]) yield lst[start:stop] start = stop This is then used in a template like this: {% for column in list|columns:"3" %} <ul> {% for item in column %} <li> <a href="{{ item.get_absolute_url }}">{{ item }}</a> … -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry.
