On 2 March 2018 at 16:39, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/01/2018 09:08 PM, Nick Coghlan wrote: > >> Adding statement local variables into that mix *without* some form of >> syntactic marker would mean taking an already >> complicated system, and making it even harder to reason about correctly >> (especially if statement locals interact with >> nested scopes differently from the way other locals in the same scope do). >> > > Seems like it would far easier and (IMHO) more useful to scale the > proposal back from a statement scope to simple expression assignment, and > the variable is whatever scope it would have been if assigned to outside > the expression (default being local, but non-local or global if already > declared as such). >
Because that would put us back in the exact same problematic situation we had when "[x*x for x in sequence]" leaked the iteration variable (only worse): no function locals would be safe, since arbitrary expressions could clobber them, not just name binding operations (assignment, import statements, for loops, with statements, exception handlers, class and function definitions). > No grammatical grit on anyone's monitor, no confusion about which variable > is being accessed, and no confusion about the lifetime of that variable > (okay, no /extra/ confusion ;) . > Unfortunately, it would mean a lot more "All I did was name a repeated subexpression and now my function is behaving weirdly". > Maybe somebody could explain why a statement-local limited scope variable > is better than an ordinary well-understood local-scope variable? > Particularly why it's better enough to justify more line-noise in the > syntax. I'm willing to be convinced (not happy to, just willing ;) . > It breaks the expectation that only a well defined subset of statement can make changes to local name bindings. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/