I’ve seen a few questions on various Python mailing lists ranging from TurboGears to SQLite that appear to be centered around failures of easy_install under Windows. The problem generally manifests itself during the installation phase of a package with the cryptic message “not a valid archive type.” (Python supports zip, tar, gzip/bzipped tars, and so forth.) Oddly, I’ve never come across a reasonable answer!

Thankfully, this particular issue isn’t difficult to solve!
Read more…

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

This article has been deprecated as the fundamental principles behind the data acquisition are flawed and incorrect (at the time, I didn’t have multiple machines to test on; as a consequence, benchmarks were performed on the same server by the same server). You should not cite this article as authoritative, but it can give you some additional foundations to base further research on.

I’ve been working with a couple of Python-based frameworks for web applications recently and have elected to try my hand at writing my own application server in Stackless Python due to its simplified concurrency model (and threading in Python appears to have performance-related issues compared to languages that support it natively, like Java). My efforts haven’t gotten much further than creating a basic skeleton so far, and it certainly seems as though I’ve learned much more about Python’s internals than I ever wanted to know! Performance has been a fairly significant concern up front, and I believe it’s necessary to examine how your own software performs early in the development process rather than waiting until the design has been solidified. Once you’ve been bitten by a fundamental flaw or serious bottleneck around which your entire design relies heavily on, it’s very difficult to alter the application’s behavior without significant refactoring. While I’ve heard it said that it’s sometimes better to write the application first and worry about performance later, I have never had such luck. It seems easier to write the application correctly the first time, in terms of developer time spent now and in the future on maintenance.

However, there is one benefit I didn’t predict from this exercise: This experience has also afforded me an opportunity to compare different frameworks and servers for performance and behavior under load. Read more…