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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4