Quickie: IPython

I love Python. It’s a beautiful language; simple, concise, and it’s a much more “pure” object-oriented language than others. (PHP, I’m looking at you.) It does have its drawbacks, mostly as a consequence of duck typing, but I can’t think of very many situations where that would present a significant drawback.[1]

In this quickie, I’d like to introduce something I recently discovered while working through a TurboGears tutorial. It’s called IPython and is an incredibly useful interactive shell. (Be aware that the IPython site doesn’t appear to be working at the moment.) For a quick overview, take a look at the Wikipedia entry. If you’d rather hear my take, here it is:

  • It supports tabbed auto-completion – You can use this to auto-complete module names (and module paths like twisted.web.http) or to inspect object methods, class methods, and just about anything else
  • It works like most common shells – Even under Windows, you can fire up IPython and obtain a reasonably Unix-like shell.
  • Looking through the Wikipedia entry, it has a few other useful features such as the capability of running blocking functions in a separate thread of execution.

With as long as IPy has been around, I’m surprised I just discovered it. I have heard of it before, but my previous biases of self-hosting language shells being rather poor apparently interfered with my desire to try new things. Try it! You won’t regret it; it’s certainly a lot easier than inspecting everything with dir() when you can’t remember whether that method was has_index or hasindex!


[1]: Some developers feel that duck typing can be met with disastrous consequences particularly in large, poorly documented projects. This school of thought generally holds that strongly typed languages are self-documenting. While I agree, I think that the drawbacks of duck typing can be mitigated by 1) taking care to ensure that published API documentation truly conform to the APIs they document, 2) making liberal use of docstrings within methods and function definitions, and 3) updating the docstrings immediately before or after a change has been made that may break compatibility with outside callers. In a perfect world, the project documentation would be in perfect sync with the source; this isn’t a perfect world, of course, and I feel that keeping docstrings consistent with the documentation at the very least is fundamentally important.

Leave a comment

Valid tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>