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
!
Footnotes
[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.
If you’ve used and built packages from source, chances are you’ve run into some derivation of this dreadful message:
libtool: link: `/usr/lib/libgnomevfs-2.la' is not a valid libtool archive
Unfortunately, there are a few potential causes ranging from broken packages to missing packages, but in general, they are the result of broken dependencies (missing packages are broken dependencies, after all!). Read on about some potential workarounds and solutions! Read more…
Some months back, I was playing around with software I had written to automatically decompress World of Warcraft addons, record their contents, and place them in a single zipped archive for download via our guild site. I ran into some peculiar issues with a handful of WoWAce-based addons that I eventually traced to the developer’s use (incorrectly, I might add) of Subversion externals. Oddly, the archive would behave correctly under Windows while using both the built-in Windows zip utility and 7-zip. That was when I started thinking about the blessing and curse of standards. Read more…