John Resig, Javascript guru, ported Processing to Javascript. The magnitude of the project gave me one of those jaw drop moments. I’m a huge fan of Processing, and to be able to write “applets” without Java…well, let’s just say I’m excited.
—★—
Everytime you linkjack a YouTube video on any number of social news websites, God kills a baby seal. Or kitten—whatever. It’s a disgusting habit and pathetic attempt at driving traffic to your website. Don’t do it.
To restore the balance to the Force, I will be vehemently down-voting/burying any submissions that follow this vile practice. Help me out, and do it too.
—★—
Quicksilver vs. Spotlight
I’m no stranger to Macs—both my parents are long-time users. My mother still has a candy green G3 tower sitting around somewhere. I, however, bounced between various versions of Windows and Linux until last December, when I picked up a shiny new Macbook.
Quicksilver was one of “those” apps I was told to get—the list that included wonders like TextMate and Adium X—and I had it installed literally minutes after I first saw Leopard’s desktop.
I learned pretty quickly that Spotlight is a pretty decent application launcher itself. This is a change from the Tiger days, when there were little nags that prevented it from being a truly functional launcher. Now, I can type, see my result and tap Enter. I can type a word into it and wait for an in-line Dictionary.app definition to show up.
Quicksilver isn’t afraid of functionality; it’s known for it’s vast library of plugins and “power-user” functionality. Spotlight definitely pales in comparison to Quicksilver’s functionality, despite the overhauls that Leopard brought. But I use Quicksilver exclusively as an application launcher. When I want to Google/Wikipedia/Internet something, I do it in Firefox—it’s almost always open anyway. When I want to control iTunes, I use the dedicated buttons the newer Macbooks (mine included) have to play/pause and skip songs. Other crazy stuff like compose new emails inline, or send text to various applications is far beyond what I want my application launcher to do.
Logic would dictate that since the core functionality that I want is inherent in both and is performed exactly the same in both, I should be using Spotlight—after all, there isn’t an extra application running in the background eating RAM by indexing on top of what the operating system is already doing. So I did: I ditched Quicksilver for a week. I re-mapped Spotlight back to its default Command-Space, and Quicksilver back to it’s default of Control-Space. I then took Quicksilver off my startup items and rebooted.
The week went well—in fact, too well. I was almost sold. I didn’t really notice any improvements from the fact that Quicksilver wasn’t running, and so I decided to, as control, go back to Quicksilver for a week.
The first moment I hit Command-Space after getting Quicksilver running again had me sold. I find Quicksilver more responsive; I love how it is in my face instead of far in the corner; I like how it indexes new applications faster; and most of all, I find I prefer how it guesses what application I want better.
Believe me, if you’ve been sold on Spotlight for application launching already, give Quicksilver a shot.
—★—
Python Decorators: Syntactic Sugar
Python decorators are syntactic sugar—you’ll hear that a lot. Decorators are an extremely powerful tool that, at first, don’t seem to offer any real use. Take, for example:
def decorator_test(function):
print function.__name__
def foobar():
print "Hello, world!"
decorator_test(foobar)
That will output foobar—quite clear, and a simple example. To convert this into decorator syntax:
def decorator_test(function):
print function.__name__
@decorator_test
def foobar():
print "Hello, world!"
Again, you’ll see the output foobar. So what happened? You’ll notice the @decorator_test line above the function definition of foobar(). This is the syntax for applying a decorator to a function. Comparing our two examples, you’ll see applying a decorator to an arbitrary function and then calling function, is the equivalent of calling decorator(function).
Why bother doing this at all? There is plenty of real-world examples for decorators, and I would consider it to be “modern” Python—it applies well to object-oriented programming, and properly, in a Pythonic way, exposes Python’s functions as first-class objects. Here’s a more practical application:
class safe:
def __init__(self, function):
self.function = function
def __call__(self, *args):
try:
return self.function(*args)
except Exception, e:
print "Error: %s" % (e)
There’s some major changes over the last example function. Firstly, I’ve encapsulated the functionality into the class; notice how it doesn’t affect the decorator. Rather than decorating a function with another function, I’d do it with a class here. To make things work, I’m using the class’ __call__ method, which is going to be how I pass the functionality to my target function. I also need to __init__ my class so that I can take the target function as a first-class object into my class. The functionality is very simple: I’m going to receive a function (self.function, created at __init__), and test it’s execution safely. I use *args to receive all arguments from the target function so that functionality is preserved and completely generalized. Here’s a sample on how to use this:
@safe
def unsafe(x):
return 1 / x
print "unsafe(1): ", unsafe(1)
print "unsafe(0): ", unsafe(0)
This outputs:
unsafe(1): 1
unsafe(0): Error: integer division or modulo by zero
Python doesn’t like when you divide by zero1, and so safe catches that and cleanly lets us know without killing the application.
This class can be used almost as a template for handling a large proportion of decorator functions; the combination of __init__ and __call__ is a lot more powerful and Pythonic—at least in my opinion—than declaring a wrapper function with another one inside it to achieve the same functionality.
Outside of Django, I haven’t really used decorators a whole lot, but spending a lot of time on Project Euler meant I needed to speed up a lot of my recursive algorithms. Decorators really came to the rescue in the form of memoization.
Let’s take a very simple Fibonacci number generator:
def fibonacci(n):
if n in (0, 1): return n
return fibonacci(n - 1) + fibonacci(n - 2)
It’s clear this is a very inefficient algorithm: the amount of function calls increases exponentially for increasing values of n—this is because the function calls values that it has already calculated again and again. The easy way to optimize this would be to cache the values in a dictionary and check to see if that value of n has been called previously. If it has, return it’s value in the dictionary, if not, proceed to call the function. This is memoization. Let’s look at our memoize class:
class memoize:
def __init__(self, function):
self.function = function
self.memoized = {}
def __call__(self, *args):
try:
return self.memoized[args]
except KeyError:
self.memoized[args] = self.function(*args)
return self.memoized[args]
This is very similar to the safe class structurally. There is now a dictionary, self.memoized, that acts as our cache, and a change in the exception handling that looks for KeyError, which throws an error if a key doesn’t exist in a dictionary. Again, this class is generalized, and will work for any recursive function that could benefit from memoization.
Let’s run a few comparisons. First, the setup:
def fibonacci(n):
if n in (0, 1): return n
return fibonacci(n - 1) + fibonacci(n - 2)
@memoize
def fibonacci_memoized(n):
if n in (0, 1): return n
return fibonacci_memoized(n - 1) + fibonacci_memoized(n - 2)
Notice how fibonacci_memoized is extremely clean—it’s the exact same function. We don’t have any extraneous cache = {} calls outside the function, and there is nothing in the algorithm that detracts from the natural flow of the process. That is what I think is the biggest benefit of decorators: it abstracts away functionality that isn’t relevant to the core of the function.
Using a simple home-brewed timer function:
Beginning trial for fibonacci_memoized(30).
fibonacci_memoized(30) = 832040 in 0.000516s.
Beginning trial for fibonacci(30).
fibonacci(30) = 832040 in 1.147118s.
The memoized function is over 2223 times faster. Even better, in this case, it scales very well.
Beginning trial for fibonacci_memoized(40).
fibonacci_memoized(40) = 102334155 in 0.000699s.
Beginning trial for fibonacci(40).
fibonacci(40) = 102334155 in 145.366141s.
The memoized function went up about 35% (an increase of 0.000183s) whereas the vanilla version went up almost 126% (an increase of 144.219023s). While the percentage values might not show a great deal of improvement, take a look at the actual values: this is effective. In fact, you can easily reach the maximum value Python will accept before you hit maximum recursion depth:
>>> fibonacci_memoized(332)
1082459262056433063877940200966638133809015267665311237542082678938909
0.009884s
I’m not going to give you a comparison—I guess I’m just not too big on leaving my laptop on for a few hours ever with the CPU working on overload. While this essentially just became a post on the glory and wonders of memoization, note how easy it was to get was to get speed improvements of several orders of magnitude by using decorator functions. I’ve already created memoize, you just have to use it. No hassle.
Here’s a bit of homework to practice your decorator-fu: write a decorator function that rounds off the output of another function down to an arbitrary precision. Email it to me (I have a contact form). Let me know if you have some cool uses for decorators, again, email me.
- Then, who does? ↩
—★—
Python and Twitter
I’m a user of Twitter, and my favorite part of the Twitter experience is the API. Twitter has allowed users access to a simple, yet expansive API that has spawned a whole community of users that create apps, bots, mash-ups etc. using Twitter.
I figured I’d write a little Python wrapper to work with the Twitter API. For some reason, I didn’t do any research, and only very recently found python-twitter. I’m not upset I spent the time—I actually like my implementation because it’s so light. Here it is:
import base64, httplib, urllib
class TwitterAPI:
def __init__(self, username, password):
# generate authentication header string
self.authentication = { "Authorization": "Basic %s"
% base64.encodestring("%s:%s" % (username, password)).strip() }
# create connection
self.connection = httplib.HTTPConnection("twitter.com", 80)
def update_status(self, status):
# send post response with authenticated status
self.connection.request("POST", "/statuses/update.xml",
urllib.urlencode({ "status": status }), self.authentication)
response = self.connection.getresponse()
return response.status
It’s pretty simple—I’ve written out update_status which, surprisingly, updates the status of the authenticated user. To use the other API functions, just adjust self.connection.request accordingly. For example, to fetch the public timeline:
def get_public_timeline(self):
# send get response--no authentication needed
self.connection.request("GET", "/statuses/public_timeline.xml")
response = self.connection.getresponse()
return response.read()
response.read() just spits out the request (which we have asked for in XML form) in it’s entirety. Use your favorite method of parsing XML in Python—alternatively, you may opt to return any of the other supported formats. A few things to point out. Notice how self.connection.request is now passed a GET parameter rather than POST—this is defined in the API and is function-specific. I didn’t need to send any further information because Twitter doesn’t require it. update_statushowever, did: status. To send a direct message, for example, you need to provide user and text for the recipient.
Simple and easy. Feel free to use and abuse this. Credit would be appreciated—or, buy me something nice.
—★—
Ode to Em-dash
I’ll cut to the chase: you’re probably using em-dashes wrong1—if you’re using them at all. I’ll use them in almost everything I write. Em-dashes convey an abrupt change in thought in a subtler and more expressive way than a colon. Take a look at the first sentence; I use a colon to force an abrupt idea on the reader, and close the sentence off with a new thought placed in that deserved a spot in the sentence with an em-dash.
Crafting the em-dash seems to be a problem. I’ll give that there doesn’t seem to be a defined standard, but the consensus does seem to sway in the direction I’m about to present. The em-dash (“—”) gets its name because it is the width of the letter “m”, known more commonly as one “em”. Unlike an en-dash (“–”), which is used mainly for ranges2, the em-dash has only one use. If setting the standard were up to me, the em-dash would be set closed between words—like so—and neither open nor replaced by an open en-dash3. There are quite a few long-standing style guides that maintain this is the proper way. There’s a problem though: what do you do with a limited character set, say, ASCII? LaTeX users would argue that “‐‐‐” (triple hyphen-minus) is the correct way, but I’d stick with just two: “‐‐”.
So please, bring back the em-dash. Use it to craft your sentences to be a bit more sophisticated—‘cause parentheses suck.
- This is not to say I have perfect grammar ↩
- There are other uses ↩
- This one confuses me. What of the em-dash then? ↩
—★—
Apparantly, because I used OpenOffice for a year a while back, I’m a software pirate. A-list blogger Jeff Atwood posted that, essentially, any developer that refuses to pay for software and instead opts for open source alternatives is a software pirate. I’ll give him that it’s a classy way to lose a lot of respect.
—★—
Getting in the Python Mindset
Early in my Python career, I discovered import this. It’s an easter egg of sorts. Here’s the output:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
It’s not like these concepts are Python-specific. Readability is important, regardless of language choice. Flat is better than nested, again, regardless of language choice; and so on, and so forth. What I love about Python—and I think it’s a community thing—is that people really take this to heart. I don’t believe C++ coders don’t strive for this, but they don’t have a word for it. Pythonists call it the Pythonic way.
It’s a strange concept for a beginner Python coder to understand, more so if said hacker has a background in a more traditional language—say, C++. Experienced coders often say there is only one right way to do something in Python, and that is the Pythonic way. It’s a mindset that isn’t easy to get into; I had trouble myself. I wasn’t writing bad code per say—it did what I wanted to, and often times, was more than speedy enough. It was just—looking back now—cumbersome, verbose and non-idiomatic. There’s obviously a lot of argument to what is the one, right Pythonic way at higher levels, but here’s a few examples.
A C++ coder would apply a function to every element in a list like this:
for (int i = 0; i < spam_length; i++) {
eggs(spam[i])
}
It’s relatively clean; the syntactic structure of the for loop in C++ is short and doesn’t require much cruft. An inexperienced Python programmer might try to implement the exact same thing like this:
i = 0
while i < spam_length:
eggs(spam[i])
i += 1
It almost hurts me to look at that! I would hope that anyone who has been hacking around in Python for even a few weeks would see how many issues there are with that code. Luckily, even a mediocre tutorial or teacher would teach a beginner that there are better ways to do that. The next stage could possibly be:
for i in range(len(spam)):
eggs(spam[i])
This is a big improvement. It eliminates the redundant i as a counter and iterates over a generated list of integers. A step in the right direction, but this still isn’t Pythonic. Lists (and tuples and dictionaries) and how they are handled are extremely tightly ingrained into how you write code in Python. I haven’t yet encountered a language where there is such a reliance on data structures as almost a part of syntax. The following highlights this well:
for element in spam:
eggs(element)
That’s it: short and sweet. I should mention I’d never take this approach—I don’t like modifying lists in-place. I would use a list comprehension and generate a new list:
[eggs(element) for element in spam]
Discovering list comprehensions changed everything. So elegant, so clean, yet incredibly powerful if you employ inline if statements or use lambda expressions. You could do it with map and a lambda expression, but map (as well as other functions that I consider to be fairly useful) are being deprecated changed to return iterators with the next generation of Python, so I guess they aren’t really Pythonic! There’s so much more that I haven’t covered and hope to sometime in the future: generators, decorators, closures, etc., and while it sounds like this post is a gushing fanboy’s proclamation against C++, Python borrows heavily from other languages. Taking great features from various languages and putting them into one is a good thing1.
If you see or write a really awesome piece of Python code, I’d love to see it; maybe a nifty little Pythonic twist on a traditional method of getting something done. Go.
Update: It’s been brought to my attention that I actually presented the idiomatic C way, rather than C++ (thanks @scott_s).
Update 2: There’s a (very minor) debate going on over at News.YC as to whether for_each actually is or isn’t the idiomatic C++ way. If you think you know, please let me know.
- Python’s decorator syntax is from Java; list comprehensions are from SETL/Haskell ↩
—★—
Apart from the fact that Google’s new App Engine is Python-based, I love how they are offering an overall more unified system than Amazon. Judging by the—for free—very liberal starter package, you could develop, host and deploy an app for nothing until you’re raking in pretty serious traffic.
—★—
Hover Menu
I’ve been a longtime user of moo.fx and then mootools before I was introduced to jQuery. I’ve never written about it, but I was immediately a fan. I love the way the scripts are really as unobtrusive as advertised. I was meddling with it recently, and came across an issue. jQuery’s animate (documentation) function is awesome, but it only animated parameters that accept numeric values. Think fontSize or borderWidth but not backgroundColor.
Mootools has this down. There’s a beautiful demonstration in the documentation that has a menu that cleanly animates both numeric and non-numeric values. A little perturbed, I started writing a plugin for jQuery to solve this before I decided to check the impressive list of already-existing plugins. I found Interface elements.
The solution is beautiful: ifx.js from the plugin completely overrides the animate function but enhances it. There are multiple new features, but the biggest one is that you can now animate across parameters like backgroundColor.
You’re going to need jQuery and ifx.js from Interface elements. The demonstration uses the latest versions of both as of this writing, with jQuery at v1.2.3 and Interface elements at v1.2. Before we continue, go and view the demonstration now.
The markup is just a simple list with a few placeholder elements. I imagine this could be used as a eye-catching menu.
<ul id="hover-menu">
<li>menu item</li>
<li>menu item</li>
<li>menu item</li>
<li>menu item</li>
<li>menu item</li>
</ul>
The CSS to style this is again, just placeholder to demonstrate the effect:
#hover-menu {
margin: 0;
padding: 0;
}
#hover-menu li {
display: block;
margin: 0;
padding: 6px;
width: 120px;
background: #333;
color: #888;
}
Now the magic happens. First, here’s the Javascript that makes everything work:
<script type="text/javascript" charset="utf-8">
$(document).ready(function() {
$("#hover-menu > li").hover(function() {
$(this).animate({
marginLeft:"6px",
color:"#ff8",
backgroundColor:"#666"
}, 200);
}, function() {
$(this).animate({
marginLeft:"0",
color:"#888",
backgroundColor:"#333"
}, 200);
});
});
</script>
A few things to point out here:
- We’re selecting all
lielements that are children of#hover-menu. This is so that we can create lists elsewhere on the same page without having the effect. - The
hoverfunction I’ve used here is stock jQuery, and takes two functions as parameters. The first is what happens onmouseover, and the second is what happens onmouseout. Take a look at the code and you’ll see I am essentially reverting back to the style elements that were originally in the CSS onmouseout. - I had a bit of trouble getting the function to animate
emunits. It works perfectly withpx, but if you want to useemyou need to increase the value by a factor of 10 (the demonstration does this). I have no idea why—let me know if you figure out what I am overlooking. - You’ll obviously want to change all the parameters in both Javascript and CSS to your liking. Again, be sure to animate to your default CSS values in the second parameter of the
hoverfunction.
And there you have it, a direct replica of the aforementioned mootools demonstration. I actually prefer this script to the mootools implementation, both aesthetically and pragmatically. I also find that the end result is a little smoother—run your mouse quickly over both and you’ll find that the jQuery implementation handles very smoothly, whereas the animation of the mootols implementation stutters sometimes. Feel free to use the code as you please, and if you haven’t done so already, check out the demonstration. Enjoy!
—★—