Library vs Framework (was Dr. Dobb's Python-URL!)

[Magnus Lycka]

Simon Brunning wrote:
> On 8/15/05, Rocco Moretti <roccomoretti at hotpop.com> wrote:
> 
>>Which lead me to the question - what's the difference between a library
>>and a framework?
> 
> 
> If you call its code, it's a library. If it calls yours, it's a framework.

Erh, it's not quite that simple. I don't know of any frameworks where
you never call code that's part of the framework. I suppose there are
libraries that e.g. use callbacks without being frameworks.

Roughly, Simon is right though. Another way of saying it is that when
you don't use a framework, you write the main function (often a main
loop) of the application, you define the program's structure, and you
might use one or more libraries for certain functions in your code. A
framework, on the other hand, will provide the main function (e.g.
an event loop) and the basic structure of the application, and you fill
in the missing pieces with your code, to make the program do what you
desire. You might still use one or more libraries in your framework-
based app. You're not likely to use more than one framework at the
same time though. That would often be like trying to sit in two
different cars at the same time.

Besides that, people usually mean big thingies when they talk about
frameworks. For instance, Python's SocketServer and similar classes
share a lot of features with frameworks. These base classes implement
the basic logic flow of the applications you use them in. Just like in
a framework, you just fill in the missing pieces by implementing some
methods in your subclasses. Still, I never heard anyone call these
classes frameworks. Maybe they're to small and simple to qualify...
(GoF [ISBN:0201633612] calls this Design Pattern "Template Method",
but these server classes aren't just instances of that pattern,
you also use their main loops, so they *are* really tiny frameworks.)

Examples of popular Python frameworks are Zope and Twisted.

Frameworks cause some problems:
* It's non-trivial to use several frameworks at the same time, since
   frameworks typically own event loops and mandate program structures.
   It's not impossible though, e.g. Twisted can use a number of different
   event loops (e.g. those of GTK+, Cocoa and Qt).

* You typically need to learn a lot about a framework before you can
   use it well. It's much more easy to approach a library piece by piece.
   This leads to a steep learning curve.

On the other hand, a well written framework should allow you to write
code which is useful outside that framework, and in other frameworks.
Using frameworks should not prevent you from writing generic and
reusable code. If it does (more than the average library), there is
something wrong with framework, or with the way you use it.

I think Andy is wrong there. He might not be wrong in practice when
it concerns certain frameworks. E.g. Zope Products are (as far as I
understand) only useful in Zope, but on the other hand, I guess that
most Zope Products would be best written as a generic library with
no Zopeisms in it, and a Zope wrapper outside that. (I know some
database adapters are written like that.)

I also think that it can be great fun to write Python code using a
framework. If a framework helps me focus on implementing the logic
I need to create, and can take care of low level junk, and also makes
my app more flexible, I'll enjoy that, even if I am somewhat restricted
in how I code. After all, if you write a big app, and don't use a
framework written by someone else, you will basically end up writing
your own framework...and that will probably restrain you as much as
a framework written by others.

In general, code is more reusable if we can avoid reliance on third
party code, whether it's libraries or frameworks, but when there are
such dependencies, framework dependencies typically cause bigger sharing
problems than library dependencies. Of course, it's better if we only
depend on something more abstract, that can be implemented in various
ways. Both Python's duck typing and concepts such as interfaces and
adapters can help us there.

It's interesting that Twisted has started to use Zope's interfaces.
We'll see if this will lead to python components that are useful in
both Zope, Twisted and in future apps and frameworks that use those
interfaces.

I'm just starting to use Twisted myself, even if I started to look at
it previously. I never really liked Zope, but I have some hopes for
Zope 3. I guess I might be much more enthusiatic, or much more
pessimistic about frameworks on a few months (or sooner)...

So far, Twisted looks fun. It has a lot of cool features, and I think
it will help me make the application I'm about to write just as flexible
as it needs to be, without too much headache.