I too use Python for my various noodlings where I don't have a pressing need to use some other language... or even if I do, I'll draft it in Python first to get my head around the problem space then think about porting it later.
Some unusual stuff I've done in Python that I happen to have online:
https://gitorious.org/bdflib is a library for working with bitmap fonts in the "BDF" file-format, one of the traditional X11 font formats. Among other things, given a font with some base glyphs and some combining glyphs, it can automatically generate all the pre-composed glyphs Unicode defines.
https://gitorious.org/macfontextractor is a library for extracting FONT and NFNT resources from Mac OS Classic resource forks. It loads them into the data structures defined by bdflib above, so you can save them out to BDF files. Currently it only supports resource forks in MacBinary-encoded files, but it shouldn't be too hard to extend it to work with AppleSingle, AppleDouble and native resource-fork support.
https://gitorious.org/python-blip (now renamed Python BPS, I couldn't change the URL) is a diff/patch tool for arbitrary binary files; a bit like bsdiff or xdelta. It produces less space-efficient diffs than bsdiff, and it's much slower than xdelta, but the BPS file-format is vastly easier to implement than either of those.
I always find it fun and interesting to see people implement random known "x" software in a language I really understand. As the presentation says, it really does help me learn something once I see it in Python, or Ruby for that matter. Both languages seem to help me grasp code.
I'm really not a fan of the UI on speaker deck presentations. Clicking seems to advance or retreat somewhat randomly (I guess based on which side), the buttons are non standard and tiny and close together, etc. A regular PDF or video or keynote/ppt is much easier.
I thought it was a video and that I couldn't find the play button at first. Then I looked for a transcript and couldn't find that either. Finally I thought maybe it was an audio player with a slideshow that follows along.
When I realized it was just a slideshow, I was disappointed. Slides are meant to highlight points, illustrate concepts, and provide focus during a presentation, but they aren't meant to replace it. The only purpose in sharing slides is so that the folks who saw the presentation can remember it better.
At my last job we used Python to write the UI for controlling train brakes (electronically controlled pneumatic railway brakes). Worked really well for us since we did a buttload of testing (with robotframework http://code.google.com/p/robotframework/ and a bunch of other things).
Tangent, but I really wish Speakerdeck wouldn't make each slide transition a new history location. I don't want to have to hit back 30 times after viewing 30 slides to get back to the page that linked me there.
I'm currently using Python to write a compiler for a language I'm playing with (which, incidentally, looks a lot like Python, but is statically typed). Targeting LLVM IR, it's worked out nicely so far.
During my studying at the University I wrote the most of homework in Python including pseudo-random numbers generators etc.
Then I found an interesting job at financial startup where people liked Django/Python combination so I used it there too. Business logic was far clearer to read than Java code from other system parts I saw (I had to describe writing documentation and diagrams describing some details of "how it works").
Python lends itself quite nicely to code-golfing, that's true. In fact I am constantly amazed of how terse Python code can be, despite the significant whitespace stuff.
from os import*
for c in read(0,9**9):r+='\n'+' '*p+dict(zip("><+-.,[","p+=1|p-=1|s[p]+=1|s[p]-=1|write(1,chr(s[p]))|s[p]=ord(read(0,1))|while s[p]:".split('|'))).get(c,'');p+=c in''and 92-ord(c)
I know, it's a JIT compiler, not an interpreter, but still... :)
I'm not an expert on this, just a linguist who happens to code a lot, but there is some serious work on the complexity of frequency ordering. The algorithms proposed by R. Rivest (1976, Communications of the ACM) produce near-optimal frequency orders online, so if you can settle for "near optimal" then the problem is hardly traveling salesman as this author claims.
Even with a traveling salesman problem you can get "near-optimal" results with an algorithm that has a reasonable run time. It's still important to note that you have such a problem though, as the fact that you're settling for "near optimal" needs to be understood.