avinash.vora ★

I’ll cut to the chase: you’re probably using em-dashes wrong¹—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 ranges²(http://en.wikipedia.org/wiki/Em_dash#En_dash “En-dash @ Wikipedia”)], 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-dash³. 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.

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 thing¹.

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.

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 li elements that are children of #hover-menu. This is so that we can create lists elsewhere on the same page without having the effect.
• The hover function I’ve used here is stock jQuery, and takes two functions as parameters. The first is what happens on mouseover, and the second is what happens on mouseout. 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 on mouseout.
• I had a bit of trouble getting the function to animate em units. It works perfectly with px, but if you want to use em you 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 hover function.

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!

I’m no Daniel Shiffman, but I can work my way around Processing well enough. My biggest gripe with it (and hey, I still use it) is that I need to write Java. At the risk of sounding far too alternative for my own taste, I’m just not a fan of Java. It gets the job done for Processing, and thankfully I don’t need to use it elsewhere. It does have the great advantage of being able to be easily distributed via applets, but I’d much, much rather use Python.

I was pretty excited when I heard about NodeBox. It is unfortunately Mac-only, but it’s fantastic. Essentially, it is Processing for Python. The commands are kind of the same, the general feel of the community and the general end-result of my little hacks are quite similar, but there are a few notable differences. While the Processing community has a huge array of third-party libraries, NodeBox has a small, but extremely high-quality set. That’s not to knock Processing’s contributers; I just like how the documentation, download links and examples are all centralized on NodeBox’s main website. I downloaded some of these libraries, and just tinkered around. I hacked together a few examples and sample code, tweaking a few things here and there.

Here’s another. These were generated using the following code:

colors = ximport("colors")
boids = ximport("boids")
cornu = ximport("cornu")

size(500, 500)
bg = rect(0, 0, WIDTH, HEIGHT, draw=False)
colors.gradientpath(bg, color(0.125, 0.2, 0), color(0, 0, 0))
colors.shadow()
nofill()

relativize = lambda x, y: (x / (1.0 * WIDTH), y / (1.0 * HEIGHT))

flock = boids.flock(10, 0, 0, WIDTH, HEIGHT)
n = 15

for i in range(n):
    flock.update(shuffled=False)

    points = [(boid.x, boid.y) for boid in flock]
    for j in range(len(points)):
        points[j] = relativize(points[j][0], points[j][1])

    t = float(i) / n
    stroke(0.2 + t * 0.4, 0.4 + t * 0.3, 0, 0.5 * t)
    cornu.drawpath(points, close = True)

Easy to read Python! There will be some NodeBox specific stuff you might not recognize, but the entire thing works so simply. Apple-R, and it runs a new, completely random trial (handled by boids). I ran the script a few times, picked two of the best in a five trial run and uploaded them. I liked it so much, I tweaked the resolution and made myself a wallpaper out of it. Here it is. It’s 1280x800, the right fit for my Macbook. If you use this, shoot me an email. If you want a specific resolution of that wallpaper, contact me. I guarantee it will be the only one like it in the world!