[prev in list] [next in list] [prev in thread] [next in thread]
List: python-ideas
Subject: Re: [Python-ideas] Function arguments in tracebacks
From: Nick Coghlan <ncoghlan () gmail ! com>
Date: 2016-12-30 15:28:47
Message-ID: CADiSq7etsRFkoBRb7=tfjg7OYUTV1wWQR5i6JfgtqvQYrNqsMw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 29 December 2016 at 08:13, Nathaniel Smith <njs@pobox.com> wrote:
> On Dec 28, 2016 12:44, "Brett Cannon" <brett@python.org> wrote:
>
> 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).
>
>
> 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.
>
Right, the reasons for the discrepancy here are purely pragmatic ones:
- the default traceback printing machinery in CPython is written in C, and
we don't currently have readily available tools at that layer to print a
nice structured argument list the way gdb does for C functions (and there
are good reasons for us to want the interpreter to be able to print
tracebacks even if it's in a sufficiently unhealthy state that the
"traceback" module won't run, so delegating the problem to Python level
tooling isn't an answer for CPython)
- displaying local variables in runtime tracebacks (as opposed to in
interactive debuggers like gdb) is a known security risk that we don't
currently provide good tools for handling in the standard library (e.g. we
don't offer str and bytes subclasses with opaque representations that don't
reveal their contents). Even if we did offer them, they'd still be opt-in
for reasons of usability when working with data that *isn't* security
sensitive.
However, neither of those arguments applies to the "where" command in pdb,
and that doesn't currently display this kind of information either:
>>> def f(x, y, message):
... return x/y, message
...
>>> f(2, 0, "Hello world")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in f
ZeroDivisionError: division by zero
>>> import pdb; pdb.pm()
> <stdin>(2)f()
(Pdb) w
<stdin>(1)<module>()->None
> <stdin>(2)f()
(Pdb)
pdb already knows what the arguments are, as it can print them if you ask
for them explicitly:
(Pdb) args
x = 2
y = 0
message = 'Hello world'
So I think this kind of change may make a lot of sense as an RFE for pdb's
"where" command (with the added bonus that projects like pdbpp could make
it available to earlier Python versions as well).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 December 2016 \
at 08:13, 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:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><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="gmail-m_4887876919299433233quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);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></div></blockquote><div><br></div><div>Right, the reasons for the \
discrepancy here are purely pragmatic ones:<br><br>- the default traceback printing \
machinery in CPython is written in C, and we don't currently have readily \
available tools at that layer to print a nice structured argument list the way gdb \
does for C functions (and there are good reasons for us to want the interpreter to be \
able to print tracebacks even if it's in a sufficiently unhealthy state that the \
"traceback" module won't run, so delegating the problem to Python level \
tooling isn't an answer for CPython)<br></div><div>- displaying local variables \
in runtime tracebacks (as opposed to in interactive debuggers like gdb) is a known \
security risk that we don't currently provide good tools for handling in the \
standard library (e.g. we don't offer str and bytes subclasses with opaque \
representations that don't reveal their contents). Even if we did offer them, \
they'd still be opt-in for reasons of usability when working with data that \
*isn't* security sensitive.<br><br></div><div>However, neither of those arguments \
applies to the "where" command in pdb, and that doesn't currently \
display this kind of information either:<br><br> >>> def f(x, y, \
message):<br> ... return x/y, message<br> ... <br> \
>>> f(2, 0, "Hello world")<br> Traceback (most recent call \
last):<br> File "<stdin>", line 1, in <module><br> \
File "<stdin>", line 2, in f<br> ZeroDivisionError: division by \
zero<br> >>> import pdb; <a href="http://pdb.pm">pdb.pm</a>()<br> \
> <stdin>(2)f()<br> (Pdb) w<br> \
<stdin>(1)<module>()->None<br> > <stdin>(2)f()<br> \
(Pdb) <br><br></div><div>pdb already knows what the arguments are, as it can print \
them if you ask for them explicitly:<br><br> (Pdb) args<br> x = 2<br> \
y = 0<br> message = 'Hello world'<br><br></div><div>So I think this \
kind of change may make a lot of sense as an RFE for pdb's "where" \
command (with the added bonus that projects like pdbpp could make it available to \
earlier Python versions as \
well).<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br></div></div><br>-- \
<br><div class="gmail_signature">Nick Coghlan | <a \
href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | \
Brisbane, Australia</div> </div></div>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic