I know we have talked a bit before about providing a means of allowing people to return custom error pages and I haven't forgotten that. The cleanup of the code and working out what the report error function should take in the way of arguments is a first step to seeing how the ability to override it could be done.
True
Anyway, comments most welcome. Is there any other basic information that should perhaps be included in such a page. For example, the name of server or virtual host etc. I don't want to include stuff which is too obvious though.
It looks good, although I wouldn't want to write an exception handler taking that many arguments. It would be best to put them all in a special object and pass the request and that object (or attach one to the other). I can think of one thing that might be helpful to know, but I'm not sure how easy it would be to get (or how valuable it would be.) I'll throw it out there so you can think about it. If PythonAutoReload is on, it would be nice to know how old (days:hours:minutes:seconds) the handler module is (measure by when it was last reloaded), and the same for the module that raised the exception (if different, or as close to it as possible if it occurred in a module not managed by the importer), excepting modules not loaded by your importer. Additonally, the names of all modules that failed a call to __mp_clone__ (you would have to save that information ahead of time, probably use a set) At a glance that would tell you: If your module was reloaded since you changed it If your module was reloaded unexpectedly If any modules failed to pass on their state when reloaded I've encoutered a number of situations where one of those was responsible for the problem, or one of those was suspected and had to be eliminated as a cause of the problem. You will have to weigh the difficulty in implementing it versus the estimated worth to the average user, however. -Dan
