On 11May2018 11:45, Tim Peters
[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.
Sorry for the huge quote, but I'm also -1 on this. It reads beautifully, but we're straight into the = vs == area and that outweighs things IMO.
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.
Disclaimer: I'm not a core dev!
Cheers,
Cameron Simpson