Archive for March, 2009

qrc file?

March 23rd, 2009 1 comment

Just started working on this new project and ran into a filetype — and an issue — I’ve never ran into before. The file’s extension is “qrc” and it’s doctype is “RCC”, but it looks very much like a straight up XML file. I did a little lookup and found out it’s Qt’s “resource system.” Qt is a set of libraries written in C++ that includes GUI, networking, thread, and many other utilities. The resource system lets you embed different types of files into your programs more easily. These “resources” are then “part of” your program… Instead of having to figure out a way to store an image somewhere and then make the connection to your program, the image becomes actually part of your software.

I had to take the “resources.qrc” file that was in the codebase and convert it to python (since I’m using PyQt). The command to convert “resources.qrc” to “” is as simple as:

pyrcc4 -o resources.qrc

PyQT 4 Ref

Categories: Python Tags:

The wet capp

March 17th, 2009 No comments

Upon moving to LA from NYC there were many things that I had to make adjustments to. The assumed: no decent subway system, sucky bagels, lack of a satisfactory pastrami sandwich. Now one thing I really came to like towards the end of my stay in NYC were cappuccinos.

Cappuccinos were my entrance into the world of coffee. Previous to my life altering experience I couldn’t muster the strength to force a cup of joe down, but after a very fateful experience at Ninth Street Espresso my life forever was lead by the bean.

Now the reason for this post is that what I came to love and cherish at Ninth Street Espresso just is so hard to find out west. Usual things to blame in LA can probably be brought up: crappy water and passionless people. But it really doesn’t just stop there. There’s an actual discrepancy in what I’m expecting when ordering a capp and what they actually give me.

After being stung more than a handful of times with mounds and mounds of aerated milk, sitting on top of my capp — like a bouncer asking you for your ID — I now tell them to: “hold the foam!”

The response I’ve repeatedly got to this request is, “ah, I think you want a latte.” This of course leads me to mentally convulse, since now there’s no way I’m going to get what I really want.

For good form I think it’s important to note Ninth Street Espresso’s definitions for their Latte and Cappuccino:

Espresso with densely textured steamed milk. 8 oz.

Espresso with mildly textured steamed milk. 12 oz.

Now, there is some talk of an infamous creature by the name of “the wet capp.” Now although this may seem to be the answer to my unrelenting desire to get the drink I’m looking for, I assure you this just ends with me looking like a tea drinker trying to fit into a coffee world.

As a funny aside there is one coffee shop out here that sometimes gives me the ‘right capp.’ There’s an inconsistency in how the different baristas make their capps and one of them actually does it right. I’d love to know why there’s the discrepancy between the different cappuccinos.

I don’t want to make this post much longer, although I think it’s worth noting that the foamy version may have some basis for being since apparently the name “Cappuccino” has something to do with a group of Italians who were known to wear a hood. Go figure.

Categories: Coffee Tags:

Revisiting long running processes in Django

March 2nd, 2009 7 comments

So in my last post on this topic I discussed different ways to handle the problem of running code that wold otherwise cripple your web server, by pushing them off to another process.

It was mentioned that there may be other ways to attack the problem, either through Python threads or Django’s signals. This post is a review of those two suggestions.

Django’s signals

I’ll attack the simpler option first, since the response to whether this solution is viable takes all of one word: no. Signals are not asynchronous by nature and therefore they do not work as a solution to the problem. It is true that you can setup signals to work asynchronously, but you’d have to employ one of the methods discussed to handle that. So if you were to use signals to handle some asynchronous work then all they would really be doing is changing the layout of that code. You’d still need something else to actually handle the asynchronous work.

I’ll offer up a simple example of how signal code looks just for completeness.

There are three pieces to signals.
1.The signal itself
2.The sending of the signal
3.The listeners of the signal

1. Setting up the signal is as simple as including a file in your application.

import django.dispatch
test_sig = django.dispatch.Signal()

2. All you need to do to send out the request to all the listeners is call “send” off the signal. In the following code snippet I’m calling the send from one of the view functions.

from django.shortcuts import render_to_response
from django.template import RequestContext
from my_project.my_app import signals
def home(request):
    return render_to_response('home.html',

3. To setup a listener you call the connect function on the signal and to have link the listener to an instance method or function. Beware: the connect call has to come after the function definition. This code can really sit anywhere within your project.

def signal_func(*args, **kwargs):
    print "Do something here"

Python’s threads

(Update: See Malcom’s comments below, which kind of nullify the positive things I wrote about threads and this problem.)

Threads are actually a very fitting way to handle this scenario. Of course the thought of using threads did cross my mind when first attacking this problem, but it’s the kind of thing I’ve ignored as an option because I know you can get yourself in trouble when you start fiddling with an animal like this, but at the same time they are very powerful and useful if used properly.

It’s really a very simple way to resolve this problem, just push off the work to another thread within the same Python application. And in Python making use of threads is actually quite simple.

Here’s a simple intro into Python threads. There are two levels of thread libraries. The lower level object is called ‘thread’ and the higher level threading module is call ‘threading’. In most cases you will probably be working with the ‘threading’ module.

Another thing to know about is the GIL (Global interpreter lock). Since Python is an interpreted language and threads seem to all be working at the same time, there has to be a way to insure that they are not both using the same objects at the same time. The GIL locks the interpreter so that each thread can safely use Python’s internal data structures. The lock keeps moving between threads pretty frequently (I think it’s something like every 100 bytes).

Important functions to know about from threading:
__init__: initializes thread
start: starts the thread
run: code that actually runs when thread is activated
join: when called waits for thread to finish before continuing

A very simple example:

from django.shortcuts import render_to_response
from django.template import RequestContext
import threading

class TestThread(threading.Thread):
    def run(self):
        print "%s starts" % (self.getName(),)
        import time
        print "%s ends" % (self.getName(),)

def threadView(request):
    testThread = TestThread()
#    testThread.join() # if you remove the first pound sign on this line the becomes synchronous.
    print "Prints right when requested just to show that the other thread is off on it's own"
    return render_to_response('test.html',
Categories: Django, Python Tags: