Friends and family alike may have noticed a small change to my blog this weekend which has been reflected in the new header banner. I have changed domains. Now, don’t be alarmed! zancarius.com will still work, but you will be redirected here to bashelton.com. Only my personal site has been updated; previous links to various incantations of zancarius.com will still work. My project sites are also unaffected as those reside on destrealm.org.
So, update your bookmarks! I don’t imagine I’ll be changing zancarius.com any time soon, but bear in mind that it might be shifted to other uses down the road!
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…
