Likewise, I code in Python with mod_wsgi, web.py, SQLAlchemy and a library I've built up of common classes and functions:

* Mod_wsgi - standard (and imho best) way to connect code to a web application.

* web.py - a framework for people who don't like frameworks. It does exactly what you want it to do and then gets out of the way.

* SQLAlchemy - the benefits of a smart ORM, from being able to define a Model in native Python to the baked-in protection against SQL injection attacks, more than justify the cognitive overhead involved in learning it.

I was very much of that opinion before as well. But I've since come to change my mind. I'd like to concentrate on those parts that are unique about the application that I write, not the stuff that every application has to do anyway. This takes a lot of time and effort to maintain, especially if you want to stay 'current' and want to compete with the rest of the market.

If what you make is limited in scope and you can easily handle the worlkload then more power to you. But I find that for me it is more efficient to reuse well written code, even if that means I can't claim I wrote 100% of the project.

If a framework limits you, then that is a good reason to roll your own. But that comes at a price, maintaining a codebase is not without cost.

I sympathize, but there seems to be so much stuff that goes into a web framework. One of these days I want to make a list, to help deciding on "create my own" vs "external".

Maybe if there are libraries for all the needs in your language, it is doable. But it seems a bit of a headache. I am not sure I even want to waste time on thinking about my own framework. It is not the most interesting problem (how to write a web framework).

I agree with your points, although i ended rolling with pylons as the foundation. It allows me to add extras such as gzip wsgi layer, secondary dbs (tokyo and mongo), and roll my own custom routes with little effort.

Completely agree. The best framework is one you've built yourself IMHO.

The best framework is the one you would have built yourself, but which is improved and promptly bugfixed by someone else. :)

I still disagree. Frameworks are usually multipurpose general 'jack of all trades master on none' type things. Unless you've built your own based on some specific use case(s).

It's extremely unlikely that it'll be improved by someone else in exactly the direction you need it to be improved based on your particular use case.

Depends how important it is to your success though.

... except where you have new employees who need to use it, and you don't have any documentation. This is, to me, the one of the best parts about using Django or Rails--the ramp up time for new hires is lessened by being able to hire experienced developers in "framework X" from the get go, or when hiring juniors one can simply point them at a tutorial.

I forgot to ask. I haven't had experience with repoze. Do you like it? Do you prefer it instead of rolling your own?

Well, I've only used repoze.who and repoze.what.

I started implementing my own .auth library before I found those two. repoze.who is exactly what I had in mind for an authentication library, and much better architected than my own solution. I don't use any of the existing plugins (apart from openid), so the real win for me is the improved design compared to whatever I could come up with.