This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients
Date 2004-07-03.01:11:02
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=357491

You're right on the self.__stderr assignment snafu; typo from when I did 
the last change to move exc_info to the class instead of the instance.  I 
hate running the Mnet test suite to trigger the bug since it is long and is 
a major resource hog.  Fixed the bug, though, and ran the testing suite; 
looks good.  Here is a sample output:

Exception in thread The Asyncore Poller (most likely raised during 
interpreter shutdown):
Traceback (most recent call last):
  File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 
442, in __bootstrap
  File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 
422, in run
  File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", 
line 133, in _asyncoreloop
  File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", 
line 59, in write
exceptions.TypeError: 'NoneType' object is not callable

As you will notice the output isn't exactly standard (extra warning about 
how exception could have come about and the addition of "exceptions" 
for the listing of what the exception was), but nothing glaring.  Is it even 
worth trying to ditch the appending of "exception"?  It would be another 
thing to store in the class (types.ClassType if I follow traceback.py).

I also took your advice and ripped out the traceback use.  So now the 
class stores a reference to _sys.exc_info and the instance stores a ref to 
_sys.stderr .
History
Date User Action Args
2007-08-23 15:37:45adminlinkissue954922 messages
2007-08-23 15:37:45admincreate