Ian Bicking: the old part of his blog

Frameworks, Libraries, Conceptual Scalability

Andrew Kuchling has a recent entry about Framelets (from this paper).

Framelets are small frameworks that can be used together. A framelet is (to quote):

I don't like the term, but the concept is important. In the past I've talked about the distinction between a framework and a library, and this is the kind of thing I'm talking about, though I consider a library to be simpler than a mini-framework (I can't make myself use the term framelet, I just can't).

The Python standard library is mostly made up of "libraries" as opposed to frameworks (though not entirely). I think of a library as:

Examples are things like pickle, shelve, urllib, csv?, etc. Even logging is more a library than a framework, despite its complexity.

It also has some more mini-framework modules, like HTMLParser, threading, urllib2, and asyncore.

Generally when I work with these mini-frameworks I have to look up the documentation each time. I still can't remember quite how to spawn threads, even though I've written code to do so many times -- the actual subset of the interface I use is simple enough, but I'm always distracted. And urllib2 has annoyed me many times in the past, because things that should be simple are not -- the excuse is that you can do anything with urllib2 by subclassing various pieces, but I think it's wrong that you should subclass anything that could be easily expected (like HTTP authentication). [John Lee has been making good progress on some improved interfaces for client web usage, though.]

Still, the mini-frameworks in the standard library are generally easier to deal with than larger frameworks -- they are relatively generic and can usually be distilled into a application-specific library-like interface. For instance, if I use HTMLParser I immediately make a function-based interface to do the specific parsing or transformation I need for my application.

It's still a challenge -- how do you make something that is easy to start with, but complete and generic enough to grow with your application? The old make easy problems easy, and hard problems possible.

I've decided to make this the more general topic of my talk on FormEncode at PyCon, describing some of the design decisions I've made in FormEncode to try to make that particular framework both easy to use and complete.

Created 13 Mar '04
Modified 14 Dec '04