On 4/25/2018 6:10 AM, Steve Holden wrote:
On Wed, Apr 25, 2018 at 4:56 AM, Tim Peters <tim.pet...@gmail.com
<mailto:tim.pet...@gmail.com>> wrote:
[Tim]
>> Binding expressions are debugger-friendly in that they _don't_ just
>> vanish without a trace. It's their purpose to _capture_ the values of
>> the expressions they name. Indeed, you may want to add them all over
>> the place inside expressions, never intending to use the names, just
>> so that you can see otherwise-ephemeral intra-expression results in
>> your debugger ;-)
[Steven D'Aprano <st...@pearwood.info <mailto:st...@pearwood.info>>]
wrote:
> That's a fantastic point and I'm surprised nobody has thought of it
> until now (that I've seen).
>
> Chris, if you're still reading this and aren't yet heartedly sick and
> tired of the PEP *wink* this ought to go in as another motivating point.
You know, I thought I was joking when I wrote that - but after I sent
it I realized I wasn't ;-)
You just don't realise how perspicacious you truly are, Tim!
It would actually be quite convenient, and far less error-prone, to
add a binding construct inside a complicated expression for purposes
of running under a debugger. The alternative is typing the
sub-expression(s) of interest by hand at the debugger prompt, or
adding print()s, both of which are prone to introducing typos, or
changing results radically due to triggering side effects in the code
invoked by the duplicated sub-expression(s). Adding a binding
construct wouldn't change anything about how the code worked (apart
from possibly clobbering a local name).
Indeed, in the cases where I currently find myself unwrapping
expressions to capture their values in local variables for debugging
purposes it would usually be far less intrusive to bind a name to the
expression inline, then use the debugger to inspect the value.
I agree that this is a definite plus feature. Being able to tag
subexpressions would make visual debuggers that show all local variables
as one steps (like IDLE's) even more useful relative to print statements.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
