[Gustavo Carneiro] >>> IMHO, all these toy examples don't translate well to the real world >>> because they tend to use very short variable names while in real world [good >>> written code] tends to select longer more descriptive variable names.
[Greg Ewing] >> I don't believe that's always true. It depends on the context. >> Sometimes, using long variable names can make code *harder* >> to read. >> >> I don't think there's anything unrealistic about this >> example: >> >> if m given m = pattern.match(the_string): >> nugget = m.group(2) >> >> Most people's short-term memory is good enough to remember >> that "m" refers to the match object while they read the >> next couple of lines. IMO, using a longer name would serve >> no purpose and would just clutter things up. [Nick Coghlan] > I've been thinking about this problem, and I think for the If/elif/while > cases it's actually possible to allow the "binding is the same as the > condition" case to be simplified to: > > if command = pattern.match(the_string): > ... > elif command = other_pattern.match(the_string): > ... > > while data = read_data(): Unless there's some weird font problem on my machine, that looks like a single "equals sign". In which case we'd be reproducing C's miserable confusion about whether: if (i = 1) was a too-hastily-typed spelling of the intended: if (i == 1) or whether they were thinking "equals" and typed "=" by mistake. If so, that would get an instant -1 from any number of core devs, who have vivid painful memories of being burned by that in C. That's not just speculation - it came up a number of times in the PEP 572 threads. > Allowing this would be part of the definition of the if/elif/while statement > headers, rather than a general purpose assignment expression. > > The restriction of the LHS to a simple name target would need to be in the > AST generator rather than in the grammar, but it's hardly the only case > where we do that kind of thing. Switching to the given expression form would > then only be necessary in cases where the condition *wasn't* the same as the > binding target. > > A similar enhancement could be made to conditional expressions (adjusting > their grammar to permit "EXPR if NAME = EXPR else EXPR") and filter clauses > in comprehensions (allowing "EXPR for TARGET in EXPR if NAME = EXPR"). In > essence, "if", "elif", and "while" would all allow for an "implied given" > clause in order to simplify the 90% case where the desired condition and the > bound expression are the same. Spell it ":=" (colon equals) instead, and a few core devs would stop objecting ;-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/