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):

• is small in size ( < 10 classes);
• does not assume main control of an application; and
• has a clearly defined simple interface.

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:

• Imperative; it does things.
• Public interface made up of functions and maybe a small number of classes (maybe one or two). Internally it may use more.
• Users do not subclass anything.

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.