Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Backwards compatibility
Backwards compatibility is pain sometimes: # We need backwards compatibility with code which spells it this way: # def my_view(): pass # my_view = cache_page(my_view, 123) # and this way: # my_view = cache_page(123)(my_view) # and this: # my_view = cache_page(my_view, 123, key_prefix="foo") # and this: # my_view = cache_page(123, key_prefix="foo")(my_view) # and possibly this way (?): # my_view = cache_page(123, my_view) -
Django 1.2.1 lançado
Django 1.2.1 lançado -
Django 1.2.1 lançado
Django 1.2.1 lançado -
Taskqueues in App Engine
App Engine has task queues as an experimental feature. There's nothing fancy here, it's just a way of queueing something up to be run later. We've probably all written a few queues in our time, the task queue is just a continuation of that. Add a URL to be executed a certain point and a scheduler will come along and try all the urls in the queue. For Arecibo we use this to do the post processing on an error. When an error comes into Arecibo we write it to the datastore quickly, we then add in one task queue that will: figure out the grouping, figure out any notifications, figure out the user agent (surprisingly a bit expensive). That post processing will be done async via the task. First thing that I noticed about the queue is that the development server doesn't run the task queue automatically meaning that all my unit tests failed. So here's a way to do it immediately if you are not in production: if os.environ.get('SERVER_SOFTWARE', '').startswith('Dev'): # send the signal, otherwise we have to clicking buttons # to process the queue send_signal(None, self.id) else: # enqueue the send notification # if development taskqueue.add(url=reverse("error-created", args=[self.id,])) … -
util
D’oh: django/contrib/admin/util.py django/contrib/admindocs/utils.py django/contrib/comments/views/utils.py django/contrib/formtools/utils.py django/contrib/gis/db/backends/util.py django/contrib/gis/tests/utils.py django/contrib/localflavor/it/util.py django/contrib/localflavor/se/utils.py django/contrib/localflavor/uy/util.py django/contrib/messages/utils.py django/core/files/utils.py django/core/mail/utils.py django/db/backends/util.py django/db/utils.py django/forms/util.py django/http/utils.py django/test/utils.py tests/regressiontests/forms/util.py -
Creating a Cacti Alternative
I want to replace cacti. I love graphs and information collation as much as the next guy, but I want something more and at the same time, something much less. I have recently finished my second year of a Computer Science course at the University of Nottingham, and thus it is time to start thinking [...] -
An inline image Django template filter
Adding image fields to a Django model is easy, thanks to the built-in ImageField class. Auto-resizing uploaded images is also a breeze, courtesy of sorl-thumbnail and its forks/variants. But what about embedding resized images inline within text content? This is a very common use case for bloggers, and it's a final step that seems to be missing in Django at the moment. Having recently migrated this site over from Drupal, my old blog posts had inline images embedded using image assist. Images could be inserted into an arbitrary spot within a text field by entering a token, with a syntax of [img_assist nid=123 ... ]. I wanted to be able to continue embedding images in roughly the same fashion, using a syntax as closely matching the old one as possible. So, I've written a simple template filter that parses a text block for tokens with a syntax of [thumbnail image-identifier], and that replaces every such token with the image matching the given identifier, resized according to a pre-determined width and height (by sorl-thumbnail), and formatted as an image tag with a caption underneath. The code for the filter is below. -
An inline image Django template filter
Adding image fields to a Django model is easy, thanks to the built-in ImageField class. Auto-resizing uploaded images is also a breeze, courtesy of sorl-thumbnail and its forks/variants. But what about embedding resized images inline within text content? This is a very common use case for bloggers, and it's a final step that seems to be missing in Django at the moment. Having recently migrated this site over from Drupal, my old blog posts had inline images embedded using image assist. Images could be inserted into an arbitrary spot within a text field by entering a token, with a syntax of [img_assist nid=123 ... ]. I wanted to be able to continue embedding images in roughly the same fashion, using a syntax as closely matching the old one as possible. So, I've written a simple template filter that parses a text block for tokens with a syntax of [thumbnail image-identifier], and that replaces every such token with the image matching the given identifier, resized according to a pre-determined width and height (by sorl-thumbnail), and formatted as an image tag with a caption underneath. The code for the filter is below. -
GSOC Status Report
So… I’ve been working on the summer of code project now for a bit. Hopefully I’ll be more productive next week, as this week was frustrating with non-SOC things. The main SOC things I did this week involved getting stuff set up to do more work next week. I spent a bunch of time setting [...] -
Backtrac Implementation – The Major Decisions
Thinking a lot about my 3rd year project, I've been considering how to implement a backup system based around a Django server. So far, I have reached the conclusion that the system will consist of three main parts: The Django server (yet to be named) The client daemon (backtracd) The backup library itself (backuplib) As [...] -
On Django And Migrations
On Django And Migrations. South author Andrew Godwin on the plans for migrations in Django. His excellent South migration library will be split in to two parts—one handling database abstraction, dependency resolution and history tracking and the other providing autodetection and the South user interface. The former will go in to Django proper, encouraging other migration libraries to share the same core abstractions. -
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 … -
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 …
