Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django Extensions 1.2.0
Django-Extensions version 1.2.0 is out now ! :) ChangeLog: More Python 3 support BACKWARDS COMPATIBILITY: Fixes to the UUID field might break backwards compatibility FEATURE: hook in dumpscript to control execution during run_import FEATURE: add --prof-file option to runprofileserver FEATURE: provide configurable way to obtain Keyczar class FEATURE: IPv6 and FQDN address support in runserver_plus FEATURE: runserver_plus setting for default address/port in settings.py FEATURE: added trvis status image FIX: JSONField did not allow empty list as default value FIX: support Django 1.5 swappable User model FIX: runserver_plus to serve static files correctly FIX: make spatialite work with reset_db FIX: sqldiff missing varchar size under PostGreSQL FIX: removed fallback uuid module FIX: sqlcreate use client hostname not database server hostname for grant FIX: graphmodels version comparison for 0.36 work around -
A Plan Comes Together
Long, hard days of coding, shuffling and teasing Oracle finally come to a close - or do they? I'm very pleased to report that, just before this blog post was published, we merged my schema-alteration branch into Django. It's been a long road, and I'd like to thank everyone who's helped me, especially those who backed my Kickstarter and my fellow core developers, all of whom have been invaluable. This isn't the end of my work, though; it's just the end of the first phase. Migrations are functional but not complete, and the schema backends are passing all of their tests but will still have a few bugs. What next? The next step is twofold; working on improving the documentation (there's still large gaps in the reference documentation), while also adding some missing features, including: Migration squashing. The underlying framework for this in place but the user-facing commands aren't written yet. More Operations, including ones for custom raw SQL and custom Python code (for more complex manipulations) Better merge detection: Currently it just errors, while instead it should be able to resolve some merges automatically. Support for out-of-transaction operations, like CREATE INDEX CONCURRENTLY on PostgreSQL. This will require a little … -
Keep that module out!
Keep that module out! We usually include a local_settings.py file in our Django projects. We use the file whenever some Django settings need to be tweaked according to the environment or specific requirements of individual developers. It was a challenge to find a good way to exclude that file from being installed in production. Read more... -
Writing thread-safe django - get_or_create
In this blog post, we'll discuss thread-safety, why it's important and how to write thread-safe django code, especially for bulk operations like management commands. We'll take a simple example - get or create. Thread-safety: Thread-safety means that our code can be run in multiple threads and behave as expected. The reason that code can be unsafe with regard to threads is because we'll be manipulating shared memory (e.g. database) from the threads and there's a chance of a race-condition which will produce unexpected results. To avoid this, we have the option of using read-write locks, transactions etc. We'll look at some simple examples and try to understand these options. The usual way: Let's consider a management command that syncs data from another source (e.g. API, remote database etc.. The correct way to do this would be to use the built-in django utility - get_or_create: Update: Updated the command to run each arg in a thread class MyThread(Thread): def __init__(self, my_id): super(MyThread, self).__init__(name=my_id) self.my_id = my_id def run(self): instance, created = MyModel.objects.get_or_create(my_id=my_id) print '%s %s' % (instance.id, created) instance.delete() return class Command(BaseCommand): args = '<my_id my_id ...>' help = 'Get or create instace of mymodel with my_id' def handle(self, *args, **options): … -
Django Round-Up #6
This week Kenneth and Brandon are joined by Russell Keith-Magee! -
Django i18n
What does i18n mean? i18n = i followed by 18 letters followed by n = internationalization That is it, just a short hand. It isn't the name of standard governmental or otherwise. When I watched the first videos about Django many years ago, they declared that Django had great internationalization support including a Welsh translation. It sounded great and I wanted to try to use it, but I was never involved in a project that really needed it, until now! At Thalmic Labs we were able to translate the company website into German and Korean in a matter of weeks, the most time was devoted to getting the translations done, very little was figuring out i18n in Django. It was only a few hours of hitting my head against the wall. Here is a bit of what I learned along the way. Hopefully it helps you. Resources First watch this excellent talk by Jacob Burch. He helps to fill in some of the gaps from the i18n documentation which you should also have a look at. Definitely grab Jacob's version of poxx, you won't need it in production or on staging so you can just install it locally: pip install … -
cookiecutter: Project Templates Made Easy
Yesterday, Jeff Knupp wrote an amazing how-to article called "Open Sourcing a Python Project the Right Way". While I was reading it, I was rather pleased by just how close it is to my own practices. Considering Jeff's amazing Writing Idiomatic Python, it meant I was on the right track. The downside, of course, is implementation. Creating reusable Python packages has always been annoying. There are no defined/maintained best practices (especially for setup.py), so you end up cutting and pasting hacky, poorly understood, often legacy code from one project to the other. Some of it does nothing and some of it fails catastrophically on Python 3. There's a term for this sort of behavior, and it's called Cargo Cult programming. Fortunately, while I was ranting and Jeff (and Hynek Schlawack) was writing, someone was making cookiecutter. cookiecutter does one thing and it does it well What cookiecutter does is make creating and maintaining project templates easy and intuitive. This allow developers of all languages (not just Python) the ability to break free from cargo-cult configuration and follow patterns dictated by the experts who present their own cookiecutter templates. So if you don't like how the author of cookiecutter's creates her … -
Cookiecutter: Project Templates Made Easy
Yesterday, Jeff Knupp wrote an amazing how-to article called "Open Sourcing a Python Project the Right Way". While I was reading it, I was rather pleased by just how close it is to my own practices. Considering Jeff's amazing Writing Idiomatic Python, it meant I was on the right track. The downside, of course, is implementation. Creating reusable Python packages has always been annoying. There are no defined/maintained best practices (especially for setup.py), so you end up cutting and pasting hacky, poorly understood, often legacy code from one project to the other. Some of it does nothing and some of it fails catastrophically on Python 3. There's a term for this sort of behavior, and it's called Cargo Cult programming. Fortunately, while I was ranting and Jeff (and Hynek Schlawack) was writing, someone was making cookiecutter. cookiecutter does one thing and it does it well What cookiecutter does is make creating and maintaining project templates easy and intuitive. This allow developers of all languages (not just Python) the ability to break free from cargo-cult configuration and follow patterns dictated by the experts who present their own cookiecutter templates. So if you don't like how the author of cookiecutter's creates her … -
Raspberry IO open sourced
Back in March, at PyCon 2013, the PSF provided each attendee with a Raspberry Pi, a tiny credit-card sized computer meant to be paired with the Python programming language. The power and portability of the Raspberry Pi has stimulated an explosion of interest among hobbyists and educators. Their uses seem to be limited only by our collective imagination. Along with that generous gift, the PSF contracted with Caktus to help tap into this collective imagination. Raspberry IO is a site dedicated to Python and Raspberry Pi enthusiasts. The goal of the site is to serve as a friendly place where anyone can learn and teach about using Python with a Raspberry Pi. We are proud to announce that Raspberry IO is now an open source project. We've written tests and documentation to help you get started and contribute your ideas to the site. Please create an issue at the github repository. We're excited about the possibilities for a site like this in the hands of the Raspberry Pi and Python communities. If you have an interesting Raspberry Pi project, then we'd love for you to tell us about it! Razzy welcomes you! -
The state of Django and Ruby on Rails - one year later
Back in 2012 I wrote a post why my preferred choice for projects I realize with Blaze IT is Django and not Ruby on Rails. Since then it got a lot of attention and is still linked in some discussions and tweets today. People asked me for an update and if it is still relevant, so here we go. Before we start let me clarify two things: Both frameworks are a solid choice. If you cite this or my last post as an "OMG look at these arguments, $foo is clearly superior" source you did not understand the intention and arguments very well. You will get stuff done with both frameworks and your app will be fully functional and working. The choice is basically arguing on a pretty high level of comfort and the differences are pretty small (but still existing) - so one framework can beat the other in certain circumstances. It is a situational and personal decision, not an universal truth. A framework will not magically fix your existing project or build your app for you. It is one potential tool in your toolbox. If you are only building an API for a mobile app it can be … -
django-sphinxdoc 1.2
After more than a year, there is finally a new version of django-sphinxdoc available. Django-sphinxdoc is a Django app that allows you to integrate documentation written with Sphinx into your site. You can also search the documentation using Haystack. The new version adds internationalization support as well as Spanish and Basque localizations. It uses class-based views now and is compatible with Haystack >= 2.1. Thanks to Mike Shantz, Josiah Klassen, Andres Riancho and Ales Zabala Alava for their contributions. Unfortunately, I currently don’t have very much time to keep improving this app. So any contribution that solves an issue or adds a new feature is very welcome. -
Routing and Prepping
Old South bugs and nemeses get eliminated, multi-database support might finally exist, and the merge is in sight. It's been a slightly slower pace of work the last few weeks because of a friend's wedding on the wonderful island of Madeira (you can read my Trip Notes if you want to know more), but there were still a few notable changes. Routers The thing I'm most excited about is database router support for migrations. South is especially bad at multi-database migrations, supporting only the bare minimum to even function, and so I wanted to improve that state of affairs for django.db.migrations. Since syncdb had just been deprecated in my branch, the allow_syncdb method on database routers seemed a little out of place. The idea was still sound - say which models can be installed in each database - but the name and usage needed adapting. Thus, it's been renamed to allow_migrate, and the migration operations have been updated to respect it. Because the new codebase operates on models (rather than tables, like South does), it can just call the router inside every operation, see what it's allowed to do, and just do it. There's a few caveats, of course; you … -
Migrating to a Custom User Model in Django
.. |--| unicode:: U+2013 .. en dash .. |---| unicode:: U+2014 .. em dash, trimming surrounding whitespace :trim: The new `custom user model configuration `_ that arrived in Django makes it relatively straightforward to swap in your own model for the Django user model. In most cases, Django's built-in ``User`` model works just fine, but there are times when certain limitations (such as the `length of the email field `_) require a custom user model to be installed. If you're starting out with a custom user model, setup and configuration are relatively straightforward, but if you need to migrate an existing legacy project (e.g., one that started out in Django 1.4 or earlier), there are a few gotchas that you might run into. We did this recently for one of our larger, long-term client projects at Caktus, and here's an outline of how we'd recommend tackling this issue: 1. First, assess any third party apps that you use to make sure they either don't have any references to the Django's ``User`` model, or if they do, that they use Django's generic methods for `referencing the user model `_. 2. Next, do the same thing for your own project. Go through … -
Combining RFID, NFC and QRCodes with django-oscar online shop
You can write a lot of tutorials about making web apps. So to make something different lets talk about using some hardware and combine it with a shop. I'll show how to use RFID, NFC and QRCodes with a django-oscar based shop. RFID is close range radio communication. It can be used in many places like in logistics to track packages, or for identification cards. You need a RFID reader and a RFID tag with the radio device. The tag may be a sticker, a clip or something else (a lot of shape and sizes). The the tag is put close to the reader the electromagnetic field induces current in the tag that powers the radio devices. It sends back data to the reader. In most simple RFID standards it will be just unique identification number. In writable tags it may be an URL pointing to the product on the website. -
An easier way to change Django cache backend between test cases
An easier way to change Django cache backend between test cases In Changing Django cache backend between test cases I showed how to use the Mock library to activate a different cache backend for individual tests. In the comments for that article, Diederik van der Boor pointed out that the same effect can be achieved in a cleaner way by using a custom “proxy” cache backend. I took the challenge and created a proxy cache backend and a decorator for switching the effective backend on the fly. First, let’s look at how to use this beast. Activate the proxy backend in the settings.py you use for running tests: CACHES = { 'default': { 'BACKEND': 'cache_switch.CacheSwitch', 'LOCATION': 'dummy://' } } Thanks to a trick adapted from the Mock library, the decorator can be used to decorate test case classes, test methods and functions. It also works as a context manager. Here are examples of each of those use cases: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21from cache_switch import cache_switch from django.test import TestCase @cache_switch('locmem://') def test_decorated_function_runs_with_locmem_cache(): # test code class MethodDecoratorTestCase(TestCase): @cache_switch('locmem://') def test_decorated_method_runs_with_locmem_cache(self): # test code … -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. All I do is stash the value of utm_campaign (set by Google or Facebook) into a cookie called wgcookie. class CampaignMiddleware(object): def process_response(self, request, response): from registry.models import Campaign if 'utm_campaign' in request.GET.keys(): if 'wgcampaign' not in request.COOKIES.keys(): # add campaign cookie c = request.GET.get('utm_campaign', None) response.set_signed_cookie('wgcampaign', c, max_age=31536000, httponly=True) return response At signup time, I read out the cookie into the users table: try: campaign_code = request.get_signed_cookie('wgcampaign', None) except: campaign_code = None user.campaign_code = campaign_code Simple! I've now got the capability to track actual revenue by campaign source - a very handy tool to identify which campaigns might warrant higher or lower spending. I'm aware this isn't rocket science, but I figured it's worthwhile sharing - it makes more sense to me to track these things directly in my own database, than to try and match data from … -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. All I do is stash the value of utm_campaign (set by Google or Facebook) into a cookie called wgcookie. class CampaignMiddleware(object): def process_response(self, request, response): from registry.models import Campaign if 'utm_campaign' in request.GET.keys(): if 'wgcampaign' not in request.COOKIES.keys(): # add campaign cookie c = request.GET.get('utm_campaign', None) response.set_signed_cookie('wgcampaign', c, max_age=31536000, httponly=True) return response At signup time, I read out the cookie into the users table: try: campaign_code = request.get_signed_cookie('wgcampaign', None) except: campaign_code = None user.campaign_code = campaign_code Simple! I've now got the capability to track actual revenue by campaign source - a very handy tool to identify which campaigns might warrant higher or lower spending. I'm aware this isn't rocket science, but I figured it's worthwhile sharing - it makes more sense to me to track these things directly in my own database, than to try and match data from … -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together … -
Simple site traffic statistics with django-basic-stats
django-basic-stats is my basic site traffic statistics application. It can be used to watch latest referrers, Google search terms that led to finding you site or for logging and analyzing mobile devices used to browse your site. -
Sharing Your Labor of Love: PyPI Quick And Dirty
A completely incomplete guide to packaging a Python module and sharing it with the world on PyPI. Abstract Few things give me caremads like Python modules I want to use that aren’t on PyPI (pronounced “pie pee eye”, or “cheese shop”, not “pie pie”!). On the other hand – as pydanny points out – the current situation on packaging is rather confusing. Therefore I want to help everyone who has some great code but feels lost with getting it on PyPI. I will be using latest opus “pem” as a realistic yet simple example of how to get a pure-Python 2 and 3 module packaged up, tested and uploaded to PyPI. Including the new and shiny binary wheel format that’s faster and allows for binary extensions (read the wheel story if you want to know more)! I’ll keep it super simple to get everyone started. At the end, I’ll link more complete documentation to show you the way ahead. Sorry, no Windows. Tools Used This is not a history lesson, therefore we will use: pip 1.4+ (if you have no pip yet, bootstraping is easy), setuptools 0.9+, and wheel 0.21+. $ pip install -U "pip>=1.4" "setuptools>=0.9" "wheel>=0.21" Please make sure … -
Sharing Your Labor of Love: PyPI Quick and Dirty
A completely incomplete guide to packaging a Python module and sharing it with the world on PyPI. Abstract Few things give me caremads like Python modules I want to use that aren’t on PyPI (pronounced “pie pee eye”, or “cheese shop”, not “pie pie”!). On the other hand – as pydanny points out – the current situation on packaging is rather confusing. Therefore I want to help everyone who has some great code but feels lost with getting it on PyPI. I will be using my latest opus “pem” as a realistic yet simple example of how to get a pure-Python 2 and 3 module packaged up, tested and uploaded to PyPI. Including the new and shiny binary wheel format that’s faster and allows for binary extensions (read the wheel story if you want to know more and watch the list at Python Wheels get greener and greener)! I’ll keep it super simple to get everyone started. At the end, I’ll link more complete documentation to show you the way ahead. Sorry, no Windows. Tools Used This is not a history lesson, therefore we will use: pip 1.4+ (if you have no pip yet, bootstrapping is easy), setuptools 0.9+, and … -
Django Single Table Inheritance on the cheap.
There was a recent question on Stack Overflow about Django Single Table Inheritance (STI). It got me thinking about how to use my FSM-proxy stuff to just be about STI. Note: this only works when all sub-classes have the same fields: the example we are going to use here is different to a state machine, in that an object may not change state after it has been created. {% highlight python %} class Sheep(models.Model): type = models.CharField(max_length=4) tag_number = models.CharField(max_length=64) class Ram(Sheep): class Meta: proxy = True class Ewe(Sheep): class Meta: proxy = True {% endhighlight %} In this case, we can fetch all sheep as ``Sheep.objects.all()``. However, this gives us the objects as ``Sheep`` instances, when we want those with `type='ram'` to return `Ram` instances, and those with `type='ewe'` to return `Ewe` instances. We can do this, by the magic of ``type().__subclasses__()``. {% highlight python %} class Sheep(models.Model): # fields as above def __init__(self, *args, **kwargs): super(Sheep, self).__init__(*args, **kwargs) # If we don't have a subclass at all, then we need the type attribute to match # our current class. if not self.__class__.__subclasses__(): self.type = self.__class__.__name__.lower() else: subclass = [x for x in self.__class__.__subclasses__() if x.__name__.lower() == self.type] if … -
Made Up Statistics
Years ago my good friend Miguel Araujo and I presented on Advanced Django Form Usage. Slide 18 of that talk mentioned some made up statistics. Here they are for reference: 91% of Django projects use ModelForms. 80% ModelForms require trivial logic. 20% ModelForms require complex logic. In Chapter 10 of Two Scoops of Django I expanded on those made up statistics: 95% of Django projects should use ModelForms. 91% of all Django projects use ModelForms. 80% of ModelForms require trivial logic. 20% of ModelForms require complicated logic. Important Disclaimer: These numbers were cooked out of thin air by yours truly. I determined them with zero research, they carry absolutely no scientific weight, and shouldn't be used in any serious argument. They are wholly my opinion, which is good or bad depending on your point of view and your own opinion of my opinions. With that out of the way, I've made a bar graph out of my fictional data: You'll notice that my bar titles could be stronger. I actually did that on purpose in case anyone tries to use that chart in real life. In any case, if you thought that was interesting, then read on. I have many …