<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 28, 2016 at 2:13 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><div class="gmail_extra"><div class="gmail_quote">On Dec 28, 2016 12:44, "Brett Cannon" <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br type="attribution"><blockquote class="m_8539567096569555848quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My quick on-vacation response is that attaching more objects to exceptions is typically viewed as dangerous as it can lead to those objects being kept alive longer than expected (see the discussions about richer error messages to see that worry come out for something as simple as attaching the type to a TypeError).</div></blockquote></div></div></div><div dir="auto"><br></div></span><div dir="auto">This isn't an issue for printing arguments or other locals in tracebacks, though. The traceback printing code can access anything in the frame stack.</div><span class="HOEnZb"><font color="#888888"><div dir="auto"><br></div><div dir="auto">-n</div></font></span></div>
<br></blockquote><div> </div><div>Right. I'd actually be more worried about security leaks than memory leaks. Imagine you're calling a password checking function that got bytes instead of text, what amounts to a type check could leak the plaintext password. One rarely sees a C traceback, let alone a textual one, except during development, whereas Python tracebacks are seen during development and after deployment.<br><br></div><div>Mahmoud<br></div><div><a href="https://github.com/mahmoud">https://github.com/mahmoud</a><br></div></div></div></div>