<br><br><div><span class="gmail_quote">On 9/2/06, <b class="gmail_sendername">Calvin Spealman</b> &lt;<a href="mailto:ironfroggy@gmail.com">ironfroggy@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 9/2/06, Brett Cannon &lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt; wrote:<br>&gt; Right, which is why the original suggestion came up in the first place.&nbsp;&nbsp;It<br>&gt; would be nice to compartmentalize exceptions entirely, but the worry of
<br>&gt; keeping a ont of memory alive for it needs to be addressed, especially if<br>&gt; exceptions are to be kept lightweight and usable for things other than<br>&gt; flagging errors.<br>&gt;<br>&gt; -Brett<br><br>So, at issue is attaching tracebacks to exceptions keeps too much
<br>alive and thus makes exceptions too heavy?</blockquote><div><br>Basically.&nbsp; Memory usage goes up if you do this as it stands now. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 If the traceback was passed<br>to the exception constructor and then held as an attribute of the<br>exception, any exception meant for &quot;light&quot; work (ie., not normal error<br>flagging) could simply decided not to include the traceback, and so it
<br>would be destroyed, removing the weight from the exception. Similarly,<br>tracebacks could have some lean() method to drop references to the<br>frames.<br></blockquote></div><br><br>Problem with that is you then lose any API guarantees of the traceback being there, which would mean you would still need to keep around 
sys.exc_info().<br><br>-Brett<br>