Simon Brunning wrote: > On 8/15/05, Terry Hancock <[EMAIL PROTECTED]> wrote: > >>On Monday 15 August 2005 09:54 am, Simon Brunning wrote: >> >>>If you call its code, it's a library. If it calls yours, it's a framework. >> >>Such concision deserves applause. ;-) > > > Thank you. ;-) > > As others have pointed out, this is a *drastic* simplification, > perhaps an oversimplification. You will inevitably need to call a > framework's code in addition to it calling yours, and a callback > argument or two won't turn a library into a framework. But I think it > captures the essence of the difference.
The point that passed me by the first time, and which Magnus et al. helped me realize, is that it's referring not to an instantaneous, mechanical view of calling, but to a more general, philosophical view of calling. With a library, the user's code is "in charge" of the program structure, and calls the library to fill in the details and help out. With a framework, the framework is "in charge", and the user code is filling in with a supporting role. With this in mind, it's easy to see why Andy Smith feels frameworks are restricting - after all, it's the framework, not the user, who is "in charge" of program structure. But I'm not sure if library vs. framework a fair comparison - the two are doing different things. With a framework, you're not really writing your own program, you're customizing someone else's. Sort of a vastly more flexible version of command line options. Saying you can't reuse code written for a framework is kind of like saying that it's difficult to use an Apache config file with the Gimp. -- http://mail.python.org/mailman/listinfo/python-list
