python

Thrush Operators in Clojure (->, ->>)

I was experimenting with some sequences today, and ran into a stumbling block: Using immutable data structures, how do you execute multiple transformations in series on an object, and return the final value?

For instance, consider a sequence of numbers,

user> (range 90 100)
(90 91 92 93 94 95 96 97 98 99)

How do you transform them such that you increment each number by 1, and then get their text representation,

"[\\]^_`abcd"

Imperatively speaking, you would run a loop on each word, and transform the sequence data structure in place, and the last operation would achieve the desired result. Something like,


>>> s = ""
>>> a = [i for i in range(90,100)]
>>> a
[90, 91, 92, 93, 94, 95, 96, 97, 98, 99]

>>> for i in range(0,len(a)):
...   s += chr(a[i]+1)
... 
>>> s
'[\\]^_`abcd'

If you knew about maps in python, this could be achieved with something like,

>>> ''.join([chr(i+1) for i in range(90,100)])
'[\\]^_`abcd'

The easiest way to do this in Clojure is using the excellently named Thrush operator (-> and ->>). According the doc,

Threads the expr through the forms. Inserts x as the
second item in the first form, making a list of it if it is not a
list already. If there are more forms, inserts the first form as the
second item in second form, etc.

It is used like this,

user> (->> (range 90 100) (map inc) (map char) (apply str))
"[\\]^_`abcd"

Basically, the line, (-> 7 (- 3) (- 6)) implies that 7 be substituted as the first argument to -, to become (- 7 3). This result is then substituted as the first argument to the second -, to get (- 4 6), which returns -2.

user> (-> 7 (- 3) (- 6))
-2

Voila!

Moving from MySQL to Cassandra – Pros and Cons

Moving on from the question of which NoSQL database you should choose, after reading these excellent posts from Digg and Twitter, I recently asked a question on StackOverflow regarding the pros and cons of moving from MySQL to Cassandra.

Stackoverflow Question is here [http://stackoverflow.com/questions/2332113/switching-from-mysql-to-cassandra-pros-cons]

I got some excellent insight and feedback, primarily from Jonathan Ellis, one of the maintainers of Cassandra, and a systems architect at Rackspace.

He’s also written a post on the Rackspace blog today as a follow up on the question.

I wanted to highlight a great tip he mentions (via Ian Eure of Digg, and also the creator of a Python Cassandra lib called LazyBoy) that was mentioned at the latest PyCon ’10,

Ian Eure from Digg (also switching to Cassandra) gave a great rule of thumb last week at PyCon: “if you’re deploying memcache on top of your database, you’re inventing your own ad-hoc, difficult to maintain NoSQL database,” and you should seriously consider using something explicitly designed for that instead.

Also mentioned are a couple of general caveats in using NOSQL vs Relational databases,

The price of scaling is that Cassandra provides poor support for ad-hoc queries, emphasizing denormalization instead. For analytics, the upcoming 0.6 release (in beta now) offers Hadoop map/reduce integration, but for high volume, low-latency queries you will still need to design your app around denormalization.

Looks like the Cassandra 0.6 beta is coming out tomorrow, and can already be built from repositories in case anyone’s interested in doing so (and telling me about their experiences!).

Rendering a drop down box in Django using ModelChoiceField

Usually, if you were to use something like,

class testform(forms.Form):
n = forms.ModelChoiceField(queryset=Models.objects.filter(id=32773), empty_label="All")


you’ll end up with a drop down box populated with “M objects” rather than a field from the model.

Instead, this works better,


class vModelChoiceField(forms.ModelChoiceField):
def label_from_instance(self, obj):
return "%s" % obj.name

class testform(forms.Form):
n = vModelChoiceField(queryset=Models.objects.filter(id=32773), empty_label="All")

t = testform()
print t

And you’re done!