Autonose: continuous test runner for python's nosetests

Today I've put up the first "releaseable" version of autonose. Basically, it analyses your code's imports, and determines exactly which tests rely on which code. So whenever you change a file, it'll automatically run the tests that depend on the changed file (be it directly or transitively). Give it a go, and please let me know your feedback.

All you need do is:

$ easy_install autonose
$ cd [project_with_some_tests_in_it]
$ autonose

See the github project page for further information (and a screenshot).

minor metaprogramming

Can anyone tell me why ruby's instance_variable_set would possibly require the name of a variable to start with an "@", rather than simply assuming it? It's a ruddy instance variable, after all...

I can find no decent alternative to python's setattr in ruby, which surprises me.

The joys of functional programming with side-effects

Quick quiz: what will the following pieces of ostensibly identical python and ruby programs print out?

If you answered "1 2 3 4" or something similar, you're half right. That's what you'll get from ruby. Surprisingly, python will give you "4 4 4 4". I'm not the first to discover this, but that doesn't make it any less startling.

The "fix" in python is to replace the lambda line with q.append(lambda i=i: puts(i)), because default function paramaters are evaluated at definition-time, not evaluation-time (another difference from ruby, potentially even related?). It makes sense once it's explained what's going on, but it's hardly obvious.

I don't know enough about how closures are done to say that python is wrong, but it's certainly less desirable and more surprising...

(for those keeping score, this makes ruby: 1, python: still heaps ;P)

P.S. I couldn't resist mentioning the title of a proposed solution to this problem: For-loop variable scope: simultaneous possession and ingestion of cake

update: As matt just pointed out, the ruby port is different in that it uses i as an argument to a block. A more faithful translation would be:

for i in (0..9)
  q << (lambda {puts i})
end

Which has exactly the same outcome as python.

So there you go. It turns out closures are confusing. Who knew? ;P

Javascript: smells like lisp

I was just struck by how lisp-ish javascript is getting (not in the powerful code-as-data way, just the "screw builtin language features, lets just use more brackets for everything" way). Exemplified by this tiny sammy example code:

$.sammy(function() { with(this) {
  get('#/', function() { with(this) {
    $('#main').text('Welcome!');
  }});
}});