Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Saved by a nose-blockage
Was slightly pleased to see today that nose-blockage saved our test suite. A change in the django-browserid library meant that on each call to login in our test suite, it was going to make a HTTP request to verifier.login.persona.org. Fortunately nose-blockage stops that request and 1,012 tests failed. If we didn't have that blockage in place, out test suite would have made over 1,012 HTTP requests to the persona.org server on each test run. That would have made our test suite slower and dependent on an external service. Not a big issue to fix, but this is a really good example of why nose-blockage can be useful to save you from libraries that change. Example failure: -------------------- >> begin captured logging << -------------------- django_browserid.base: INFO: Verification URL: https://verifier.login.persona.org/verify requests.packages.urllib3.connectionpool: INFO: Starting new HTTPS connection (1): verifier.login.persona.org blockage.plugins: WARNING: Denied HTTP connection to: verifier.login.persona.org --------------------- >> end captured logging << --------------------- -
Lettuce - scenario based tests for Django and other frameworks
lettuce is a test system driven by scenarios used in behavior driven development (BDD). The scenarios are described expressively in English and can be read and understood even for non programmers. Test system like lettuce parsers the scenarios and executes required tests for each step. -
Django import export
django-import-export is a Django application and library for importing and exporting data with included admin integration. Features: support multiple formats (Excel, CSV, JSON, ... and everything else that tablib support) admin integration for importing preview import changes admin integration for exporting export data respecting admin filters Define import-export resource example class BookResource(resources.ModelResource): class Meta: model = Book widgets = { 'published': {'format': '%d.%m.%Y'}, } Integrate with admin Source code and example app are available on GitHub: https://github.com/bmihelac/django-import-export Documentation: https://django-import-export.readthedocs.org/en/latest/ django-import-export is currently beta software. -
Full screen WebView Android app
I decided to make an Android app for my Bible memory verse site (created using Django). The main motivation for the app is to get rid of the unnecessary and annoying address bars and status bars when using the site on an Android phone. The site is already designed to adapt to mobiles, so I'm not creating a native app — I just want a better way to access the web app from an Android phone. I tried appsgeyser, but discovered they put adverts on your site, which I definitely don't want — this is an entirely free app, for a free (and ad-free) site. My requirements are: Full screen without any controls ever popping up, because you don't need them. Progress bar for page loading. Javascript works. Links work as expected. Back button works like builtin browser, until you get back to the home page, where it will cause the app to exit. There are lots of pages and wizards with solutions for bits of these, but putting them together turned out to be harder — for example, it seems that the normal way of showing a progress bar for the whole window doesn't work if you've gone full … -
Docstring inheritance in Django REST framework
Django REST framework has a nice html-based interface that, for every one of your REST views, renders the docstring as an explanation at the top of the page. Those views, they're class based views, at least the ones I use. I'm making views that ought to be base views for other Django app's API. We have a bunch of django apps for various data sources that can present their data in more or less the same way. So... I've put a decent docstring, explaining the API, in my base views. Only... they didn't show up in the interface for the subclasses. Apparently docstrings aren't inherited by subclasses! So I asked a question on stack overflow and promptly got an answer. What I ended up doing was modifying .get_description(), the method Django REST framework uses to grab and render the docstring: import inspect # Fancy standardlibrary Python internal inspection tool. import docutils from django.contrib.admindocs.utils import trim_docstring from django.utils.safestring import mark_safe .... class MyBaseAPIView(...): def get_description(self, html=False): description = self.__doc__ # Our docstring. if description is None: # Try and grab it from our parents. try: description = next( cls.__doc__ for cls in inspect.getmro(type(self)) if cls.__doc__ is not None) except StopIteration: pass … -
Enable APIs for your django apps in djangoish way
A small django helper to let you create and manage app-centric API url mappings. django-api-enabler lets you: Enable/disable APIs associated with any specific app. Enable/disable entire project APIs. Use prefix like '/api/' to identify and distinguish between API and non-API URLs. The URL to view maps are maintained within app code. Customizable app specific prefixes. urlconf compliant. Simple, yet powerful and useful! For details: https://github.com/subhranath/django-api-enabler -
Django Extensions 1.0.2
Minor version update Django-Extensions 1.0.2 is out. This release fixes the following problems: tests: fix keyzcar test failure: ImproperlyConfigured: You must set the ENCRYPTED_FIELD_KEYS_DIR setting to your Keyczar keys directory. fields: fix docstring for UUID docs: Make README links clickable and organized. show_urls: Revive --unsorted option Added LoggingBaseCommand that logs run time errors to Python logger django.commands -
Shortcomings in the Django ORM and a look at Peewee, a lightweight alternative
In this post I'd like to talk about some of the shortcomings of the Django ORM, the ways peewee approaches things differently, and how this resulted in peewee having an API that is both more consistent and more expressive. Alex Gaynor, one of the more outspoken core developers on the Django project, gave a great talk at ChiPY titled "Why I Hate the Django ORM" (slides). I think he did a great job identifying what I agree are the two biggest issues with Django's ORM: inconsistent API lack of composability The Django ORM has an inconsistent API Django wants to expose consistent APIs The framework should be consistent at all levels. Consistency applies to everything from low-level (the Python coding style used) to high-level (the “experience” of using Django). On the whole I think Django does a good job with this - the big exception being the ORM. Alex gives 4 examples, which should be familiar to Django developers and which are indicative of the underlying issues: filter(field_name=value) Q(field_name=value) F('field_name') Aggregate('field_name') filter() is the most basic method and is the most common. It is used to express a SQL Where clause and takes as parameters a list of keyword arguments … -
Shortcomings in the Django ORM and a look at Peewee, a lightweight alternative
In this post I'd like to talk about some of the shortcomings of the Django ORM, the ways peewee approaches things differently, and how this resulted in peewee having an API that is both more consistent and more expressive. Alex Gaynor, one of the more outspoken core developers on the Django project, gave a great talk at ChiPY titled "Why I Hate the Django ORM" (slides). I think he did a great job identifying what I agree are the two biggest issues with Django's ORM: inconsistent API lack of composability The Django ORM has an inconsistent API Django wants to expose consistent APIs The framework should be consistent at all levels. Consistency applies to everything from low-level (the Python coding style used) to high-level (the “experience” of using Django). On the whole I think Django does a good job with this - the big exception being the ORM. Alex gives 4 examples, which should be familiar to Django developers and which are indicative of the underlying issues: filter(field_name=value) Q(field_name=value) F('field_name') Aggregate('field_name') filter() is the most basic method and is the most common. It is used to express a SQL Where clause and takes as parameters a list of keyword arguments … -
Shortcomings in the Django ORM and a look at Peewee, a lightweight alternative
In this post I'd like to talk about some of the shortcomings of the Django ORM, the ways peewee approaches things differently, and how this resulted in peewee having an API that is both more consistent and more expressive. Alex Gaynor, one of the more outspoken core developers on the Django project, gave a great talk at ChiPY titled "Why I Hate the Django ORM" (slides). I think he did a great job identifying what I agree are the two biggest issues with Django's ORM: inconsistent API lack of composability The Django ORM has an inconsistent API Django wants to expose consistent APIs The framework should be consistent at all levels. Consistency applies to everything from low-level (the Python coding style used) to high-level (the “experience” of using Django). On the whole I think Django does a good job with this - the big exception being the ORM. Alex gives 4 examples, which should be familiar to Django developers and which are indicative of the underlying issues: filter(field_name=value) Q(field_name=value) F('field_name') Aggregate('field_name') filter() is the most basic method and is the most common. It is used to express a SQL Where clause and takes as parameters a list of keyword arguments … -
Shortcomings in the Django ORM and a look at Peewee, a lightweight alternative
In this post I'd like to talk about some of the shortcomings of the Django ORM, the ways peewee approaches things differently, and how this resulted in peewee having an API that is both more consistent and more expressive. Alex Gaynor, one of the more outspoken core developers on the Django project, gave a great talk at ChiPY titled "Why I Hate the Django ORM" (slides). I think he did a great job identifying what I agree are the two biggest issues with Django's ORM: inconsistent API lack of composability The Django ORM has an inconsistent API Django wants to expose consistent APIs The framework should be consistent at all levels. Consistency applies to everything from low-level (the Python coding style used) to high-level (the “experience” of using Django). On the whole I think Django does a good job with this - the big exception being the ORM. Alex gives 4 examples, which should be familiar to Django developers and which are indicative of the underlying issues: filter(field_name=value) Q(field_name=value) F('field_name') Aggregate('field_name') filter() is the most basic method and is the most common. It is used to express a SQL Where clause and takes as parameters a list of keyword arguments … -
Shortcomings in the Django ORM and a look at Peewee, a lightweight alternative
In this post I'd like to talk about some of the shortcomings of the Django ORM, the ways peewee approaches things differently, and how this resulted in peewee having an API that is both more consistent and more expressive. Alex Gaynor, one of the more outspoken core developers on the Django project, gave a great talk at ChiPY titled "Why I Hate the Django ORM" (slides). I think he did a great job identifying what I agree are the two biggest issues with Django's ORM: inconsistent API lack of composability The Django ORM has an inconsistent API Django wants to expose consistent APIs The framework should be consistent at all levels. Consistency applies to everything from low-level (the Python coding style used) to high-level (the “experience” of using Django). On the whole I think Django does a good job with this - the big exception being the ORM. Alex gives 4 examples, which should be familiar to Django developers and which are indicative of the underlying issues: filter(field_name=value) Q(field_name=value) F('field_name') Aggregate('field_name') filter() is the most basic method and is the most common. It is used to express a SQL Where clause and takes as parameters a list of keyword arguments … -
Django 1.5 Custom User GeoManager
AttributeError: ‘GeoManager’ object has no attribute 'get_by_natural_key’ Using geo fields on a Django model requires the use of GeoManager. Custom User models require an object manager that implements BaseUserManager.get_by_natural_key. If you’re trying to add geo fields to your custom User model you’ll need create a custom manager that mixes a user manager and GeoManager. Lucky us, this is a piece of cake! http://gist.github.com/4291351 -
Caktus Celebrates 5 Year Anniversary
Caktus celebrated the end of our fifth year in business recently. We threw ourselves a party and invited our local friends who helped us grow from our infancy through our awkward phases into a successful and sustainable small business. We started out as four college friends moving across the country from the corn fields of Indiana to Carrboro, North Carolina to work together building awesome interactive web applications. We were ready to put what we had learned in school to work and continue to learn and develop new technical and business skills. Since then we've grown, steadily bringing on developers, an office manager, project managers, and a designer totaling 15 people in all. We were fostered locally by Carrboro Creative Coworking as a technical and creative hub for the Carrboro area and by the incredible number of local technology companies in the Raleigh-Durham-Chapel Hill Research Triangle area. The party was to celebrate that local community, but we have made amazing connections all over the world. We wish everyone could have been there but had a wonderful time with those who attended while talking, reminiscing, and speculating about Caktus' future. Through all of this growth and change we have maintained the … -
RestORM - The client side of REST
RestORM structures the way you access a RESTful API and allows you to easily access related resources. It tries to be as generic as possible so it's not tailored to any specific API or server-side API library. With RestORM you can mock an entire API and replace the real client with a mock version in unit tests. RestORM is very extensible but offers many functionalities out of the box to get you up and running quickly. -
My requirements.txt
Every developer has their go to list of packages they use when starting out a new project. I thought I’d list my basic set of packages that I use for almost all of my projects. I got this idea from Daniel Greenfeld, you can check out his list here. Django Django is my go to framework. You can easily get a project going in a couple minutes. I’m using 1.4.2 in production and 1.5 in development. You can read about the changes to Django 1.5. django-secure django-secure provides you with a checklist of things you can do to make your site more secure. I include it to help me from forgetting about certain settings. django-model-utils Provides a number of useful mixins and utilities to help with certain pitfalls in Django. Status Field and Inheritance Manager are two very useful things. psycopg2 A no brainer if you’re using Postgres. Make sure you have XCode installed if you’re installing psycopg2 on OS X. django-debug-toolbar This tool gives you the ability to dig deep into the performance of your site. Just having the ability to quickly see how many queries are being run on a specific page is worth the installation. South Sanely … -
Heroku: Running multiple python processes in a single dyno using foreman
Recently I've made a few small python web projects that I've deployed on Heroku. For some of these projects I've needed to run asynchronous jobs through Celery. Heroku allows you to run one free dyno (or actually they give you 720 free dyno hours per month, which corresponds to one dyno constantly running). This means that if you choose to run one web dyno and one worker dyno (celery in this case), you'll be charged for 720 dyno hours. However, if you have a very small project, or your're working on a project that hasn't been released yet, you can avoid this cost. A heroku dyno is like a process, and in this process you can actually spawn new processes, as long as you stay within the limit of 512 mb ram (the process also only has one CPU core). Heroku suggests that you use foreman when you run your application on your local machine, but you can actually use foreman on heroku, in order to run multiple processes in a single dyno. Instructions 1. The first thing we'll do is to create a post_compile script in the bin directory of our project. In this script we'll add a few … -
Community Contributions: A Follow-Up
A few months ago, I wrote a blog post about contributing to community. A month later, that post was republished by the folks at Red Hat, in their online magazine OpenSource.com. When that article went up, I had a chance to read through it again and realized that there were a few things I forgot the first time around. In case there was any question, here's why community is so important: Lynn Root's PyCarolinas Keynote: Community FTW As with the first article, I'm focused on the communities in which I am actively involved - Django and Python - but I'm convinced that these suggestions apply to just about any open source community. On that note, here are some additional things you can do if you want to give back to open source: Answer questions in user groups. The two most active user groups in the Python world are probably Django users and comp.lang.python. Yes, sometimes the same questions seem to be asked over and over again, but there are always people new to the language or framework who need help finding their way - be a pal and help them find answers. Answer questions on StackOverflow. StackOverflow has channels for … -
Developer Time
This blog post got started with a tweet. That tweet got retweeted a lot by developers. And system administrators. And database administrators. And any creative type. As of December 7th, 2012, it had been retweeted over 500 times, a personal best. Obviously I struck a chord that resonated with a lot of people. Developers should have 4-6 hours of uninterrupted activity each day. Each 3-5 minute interruption costs more than you can imagine.— Daniel Greenfeld (@pydanny) December 3, 2012 Why did this tweet resonate with so many people? What I said in that tweet was not new - dozens if not hundreds of others have tweeted similar thoughts before and gotten many retweets. Heck, it's been written about in blogs and articles for years, either as a huge rant or often as an effort to politely educate others on how to set up a developer/operations/creative shop. I think this is because developers/engineers/creatives (and good managers) know that even a tiny distraction to someone "in the zone" takes more than just the 3-5 minutes it takes for you to finish a question and get an answer. Plus, because you are trying to remember the pieces in your head, you won't be … -
Developer Time
This blog post got started with a tweet. That tweet got retweeted a lot by developers. And system administrators. And database administrators. And any creative type. As of December 7th, 2012, it had been retweeted over 500 times, a personal best. Obviously I struck a chord that resonated with a lot of people. Developers should have 4-6 hours of uninterrupted activity each day. Each 3-5 minute interruption costs more than you can imagine.— Daniel Greenfeld (@pydanny) December 3, 2012 Why did this tweet resonate with so many people? What I said in that tweet was not new - dozens if not hundreds of others have tweeted similar thoughts before and gotten many retweets. Heck, it's been written about in blogs and articles for years, either as a huge rant or often as an effort to politely educate others on how to set up a developer/operations/creative shop. I think this is because developers/engineers/creatives (and good managers) know that even a tiny distraction to someone "in the zone" takes more than just the 3-5 minutes it takes for you to finish a question and get an answer. Plus, because you are trying to remember the pieces in your head, you won't be … -
Developer Time
This blog post got started with a tweet. That tweet got retweeted a lot by developers. And system administrators. And database administrators. And any creative type. As of the time of this posting it had been retweeted over 170 times, a personal best. Obviously I struck a chord that resonated with a lot of people. Developers should have 4-6 hours of uninterrupted activity each day. Each 3-5 minute interruption costs more than you can imagine.— Daniel Greenfeld (@pydanny) December 3, 2012 Why did this tweet resonate with so many people? What I said in that tweet was not new - dozens if not hundreds of others have tweeted similar thoughts before and gotten many retweets. Heck, it's been written about in blogs and articles for years, either as a huge rant or often as an effort to politely educate others on how to set up a developer/operations/creative shop. I think this is because developers/engineers/creatives (and good managers) know that even a tiny distraction to someone "in the zone" takes more than just the 3-5 minutes it takes for you to finish a question and get an answer. Plus, because you are trying to remember the pieces in your head, you … -
Django REST framework: migrating from 0.x to 2.x
We used Django REST framework for a while now. Nothing spectacular yet. In most cases we're only returning a bit of JSON. We chose Django REST framework over Piston because that one was effectively unmaintained at the time. We chose it over tastypie because of the great way in which Django REST framework presents your API in the browser (the "browseable API" they call it), which is very helpful if you want others to actually use your API! And... Django REST framework uses Django's class based views, which we're using a lot. So it matches the style we want to work with. This was a second thing that gave it an edge over tastypie for us. Well, anyway, most of our Django REST framework 0.3.3 (or 0.4 or whatever) views looked like this: from djangorestframework.views import View as JsonView class SomeView(JsonView): def get(self, request): return {'some': 'dictionary', 'or': ['a', 'list']} JsonView would take care of converting everything that came in/out of the get() or post() between JSON and whatever Python data structure it represents. Handy. Since 30 october, version 2.0 is out. Lots of improvements and, from what I read, a better fit for many projects. But, boy, is it … -
Temporary standing desk at work
I've got a standing desk at home that I quite like. So I thought "why not also try it at the office?". My poor desk is now lacking four screws: every leg is only using one screw for the very last hole in the legs. Stable enough for a temporary test, but not something that I want all the time. So I'll have to find longer legs or a different desk. And it'll have to be some 5 cm higher, too. The main difference with my home desk is the amount of time I spend behind it: a full 8 hour working day (instead of a couple of hours in the evening at home). I've been at it for a few days now and it works out quite fine. Some quick observations: I walk around a lot more. If I want to ask something of someone sitting two desks away I'll just walk over instead of talking to him while sitting in my chair. I feel active at the end of the day! A bit tired in my legs, but I feel at least 2 cm taller. Discussing with a colleague often means sitting down for a minute (=getting a … -
Intersphinx links to Django's documentation
Intersphinx is a very neat way to point at other projects' documentation from within your own. Handy if you want to reference a Python module or an official Django setting or class. You have to do some setup work, like enabling the intersphinx extension. Most of the time, your automatically generated sphinx configuration will already have it enabled out of the box. Now you need pointers at the other projects' documentation (there needs to be a special objects.inv file with link target definitions). At the end of your file, add something like this: intersphinx_mapping = { 'python': ('http://python.readthedocs.org/en/v2.7.2/', None), 'django': ('http://django.readthedocs.org/en/latest/', None), 'sphinx': ('http://sphinx.readthedocs.org/en/latest/', None), } Now you can do fun stuff like this: Django knows about your URL configuration because you told it where to find it with the :django:setting:`ROOT_URLCONF` setting. Only... I got an error: ERROR: Unknown interpreted text role "django:setting". What? I couldn't figure it out and asked a question on stackoverflow. I got some tips, but couldn't get it to work. Then I got an idea. Sphinx has a lot of things build in, but not Django's custom Sphinx roles like setting! That's not a standard Sphinx one. Perhaps you need to copy/paste the other project's … -
Using Configurable User Models in Django 1.5
With the upcoming release of Django 1.5 one of the largest changes is that you can now specify your own User model. If you’re fine with Django’s current User model than you don’t have to change any code. If you want to take advantage of this new functionality then keep on reading as I’ll go through how to migrate your current application to the new configurable user model. Getting Started For the sake of simplicity let’s make our own User object that is exactly the same as Django’s current but fixes the email max_length field to comply with RFC 5321 of 254 characters and adds a required field for the user’s twitter handle. # myapp.models.py from django.contrib.auth.models import AbstractBaseUser class MyUser(AbstractBaseUser): username = models.CharField(max_length=40, unique=True, db_index=True) email = models.EmailField(max_length=254, unique=True) twitter_handle = models.CharField(max_length=255) ... USERNAME_FIELD = 'email' REQUIRED_FIELDS = ['twitter_handle'] You’ll notice a few new things about this: Inheriting AbstractBaseUser: This adds a few helper fields such as password and last_login as well as methods for setting the users password, getting the username, checking if the user is active. You can checkout a full list of what it includes here. USERNAME_FIELD: This is a string describing the name …