On Wed, Apr 25, 2018 at 1:43 PM, Steven D'Aprano firstname.lastname@example.org wrote:
On Tue, Apr 24, 2018 at 08:10:49PM -0500, Tim Peters wrote:
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 ;-)
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.
Yes, I'm still reading... but I use pdb approximately zero percent of the time, so I actually have no idea what's useful for single-stepping through Python code. So I'm going to write 'blind' here for a bit; do you reckon this sounds reasonably accurate?
-- existing rationale -- Naming the result of an expression is an important part of programming, allowing a descriptive name to be used in place of a longer expression, and permitting reuse. Currently, this feature is available only in statement form, making it unavailable in list comprehensions and other expression contexts. Merely introducing a way to assign as an expression would create bizarre edge cases around comprehensions, though, and to avoid the worst of the confusions, we change the definition of comprehensions, causing some edge cases to be interpreted differently, but maintaining the existing behaviour in the majority of situations. -- end existing rationale, begin new text --
Additionally, naming sub-parts of a large expression can assist an interactive
debugger, providing useful display hooks and partial results. Without a way to
capture sub-expressions inline, this would require refactoring of the original
code; with assignment expressions, this merely requires the insertion of a few
name := markers. Removing the need to refactor reduces the likelihood that
the code be inadvertently changed as part of debugging (a common cause of
Heisenbugs), and is easier to dictate to a student or junior programmer.
-- end --