Simon Brunning wrote: > On 8/15/05, Rocco Moretti <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
