[Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

[Terry Reedy]

On 4/25/2018 6:10 AM, Steve Holden wrote:
> On Wed, Apr 25, 2018 at 4:56 AM, Tim Peters <tim.peters at gmail.com 
> <mailto:tim.peters at 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 <steve at pearwood.info <mailto:steve at 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