This proposal looks on the surface to be useful but the more I think about it, the feature look like it would be awful for those of us who try to write side-eff

This proposal looks on the surface to be useful but the more I think about it, the feature look like it would be awful for those of us who try to write side-effect-free code whenever possible. The assignments made here leak their references to all following statements, making it much harder to track the actual ramifications of any of these assignments. I'd say this is in stark contrast to PEP 3150 which tries to solve similar problems but does so by introducing functional let-style statement-local assignments, retaining an amount of "encapsulation" of expressions and their sub-expressions. > You can see it as a limitation of pdb, but many tools only have the granularity of whole line As somebody who likes to write quite "functional" code, I do see this as a significant limitation. But it's one that I'd really like to see addressed rather than used to restrict our ability to express our intentions in succinct ways. > write code for babies! I strongly disagree with this notion. Professional developers are supposed to be professionals, as in, people whose (paid!) job is to write code full-time. It's a discouraging trend to be principally structuring your engineering project around the abilities of (full-time!) coders who can often had rings run around them by amateurs. Code written "for babies" (presumably omitting language features because some may not know them) tends to turn into a long winded mess all too quickly. How are babies ever supposed to learn to be anything else if all they ever see is baby code? > I'm trying to write a single instruction per line whenever possible I'm glad he phrased it like this, because I find reading code written like this uncannily like reading assembly.