Ian Bicking wrote: > I've been using one of several systems to catch unexpected > exceptions and log them (e.g., write to a file, display on > web page, email me, etc). But many are built into a > particular system, or have an interesting but incomplete > set of features... > I feel like there must be something out there, since every Python > programmer has to deal with this sort of thing to some degree...?
And I replied: > I feel that way, too, but haven't found it...If we could put our > many heads together, I think this would be doable for the stdlib. Ian: > I'm not optimistic about a good exception handler in the standard > library; development slows down a lot at that point, and it's not a > reasonable candidate until it is designed and used Sure; I understand it's a long process, and should start independently. Me again: > Here are the pieces of the framework, by the way, which might also > benefit from some standardization: > > 1. Thread-safe application state > 2. Logging (+ exception handling) > 3. Configuration data (reading from various sources) > 4. Registry of Workers for getting things done on a schedule, > possibly recurring > 5. Registry of startup/shutdown functions > 6. Registry of active user interfaces > > I think the first three are all good candidates for a standard. > If we had a standard, thread-safe Application object, the rest > could be registerable plugins for that. You'd basically register > callbacks for app.startup and .shutdown methods to iterate over. Ian: > Hmm... I'm confused by these bits. Are you talking about > libraries for other parts of a web framework, besides exception > handling? If so, you might want to look into WSGI... Those are the bits I pulled out as specifically non-web-specific, which could be used for any kind of app (and tend to get rewritten for every framework). If your app is single-process, multi-threaded, it needs a state manager so two threads don't load or destroy global resources simultaneously. Most apps need logging and uncaught exception handling (as you noticed). Etcetera. One way to meet these needs once-and-for-all would be to have a (eventually standard) library for them, where you could mix and match the pieces you needed. So, you could write WSGI consumers of them, but they wouldn't be WSGI-specific in my mind. If they were, they'd just add to the "several systems" you were lamenting... ;) Robert Brewer MIS Amor Ministries [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
