I used to feel that way (Too Many Options is intuitively dangerous, because you believe some of your end-to-end integration will be lost if you can't guarantee one of the components). I've found that it isn't the truism I thought it was. I recently put a lot of work into CherryPy and Dejavu (to name a couple of my larger projects), allowing options where there used to be One Way. I've found time and again that if I rephrase the issue from "I'm going to lose functionality if I break this up" to "those users who choose a different component will pay the [performance|development|maintenance] penalty for their own choice", I sleep much better at night.
For example, I support using "shelve" as a data store with Dejavu. For simple queries and small stores, it beats the pants off RDBMS's. But because it is a builtin StorageManager, it has to support the full interface, including multirecall (both INNER and OUTER JOINs). Now that part is SO much slower than with DB's, that it's only usable with toy, demo datasets. But I have no problem with that, because it's a choice I leave to the deployer; they may decide their app has few enough multirecall's to make the tradeoff worthwhile. Perhaps it's something about Python itself, or perhaps my design skills have improved, or my sensibilities changed. But I should think you could find a way to say, "fine, use Cheetah; if you don't use Kid, you don't get this nice i18n tool (unless you port it! ;). Your choice." My 2 cents. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED]
