[Guido] > The use case I am guessing from your example (passing a > traceback as a single string across an RPC boundary) isn't all that > common and you ought to have only one place in your RPC package where > you need to call it.
*this* use-case isn't that useful, true. but many times, frameworks need to store the exception details "for later", for example, unit-testing. you want to run the entire test, and print a report later. if exceptions formatted themselves (via repr or something like it), all of these use cases would have been trivial, and there would be no need for the traceback module at all or excepthook. (we would still need excepthook, but only in order to redirect printouts to other file objects other than stderr.) imho it's more pythonic to have the exception object be self-contained, rather than having its state scattered around different modules (sys, exceptions, and traceback). besides, today exceptions are made of three separate "components" (type, value and tb), which can all be unified once string exceptions are removed and exceptions become new style classes. if pep 344 is going to solve that, of course i'm +1 and there's no need for a "competing" version... but the pep has been dormant for so long that i thought it was neglected. is this pep going to make it for py3k? any pronouncement on the subject? -tomer _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
