[Python-ideas] Ruby-style Blocks in Python Idea

[Stephen J. Turnbull]

Terry Reedy writes:

 > Like many other Pythonistas I recognize that that an uninformative stock 
 > name of '<lambda>' is defective relative to an informative name that 
 > points back to readable code.  What I dislike is the anonymity-cult 
 > claim that the defect is a virtue.

That's unfair.  Python has "anonymous blocks" all over the place,
since every control structure controls one or more of them.  It simply
requires that they be forgotten at the next DEDENT.  Surely you don't
advocate that each of them should get a name!

I think this is a difference of cognition.  Specifically, people who
don't want to name blocks as functions may not abstract processes to
signatures as easily, and reify whole processes (including all free
identifiers!) as objects more easily, as those who don't think naming
is a problem.

 > Since I routinely use standard names 'f' and 'g' (from math) to name 
 > functions whose name I do not care about, I am baffled (and annoyed) by 

If the cognition hypothesis is correct, of course you're baffled.  You
"just don't" think that way, while he really does.  The annoyance can
probably be relieved by s/a developer/some developers/ here:

 > (repeated) claims such as "Having to name a one-off function adds 
 > additional cognitive overload to a developer." (Tav).

I suspect that "overload" is a pun, here.  Your rhetorical question

 > Golly gee, if one cannot decide on standard one-char name, how can
 > he manage the rest of Python?

has an unexpected answer: in the rest of Python name overloading is
carefully controlled and scoped into namespaces.  If my cognition
hypothesis is correct, then a standard one-character name really does
bother/confuse his cognition, where maintaining the whole structure of
the block from one use to the next somehow does not.  (This baffles
me, too!)

The question then becomes "can Python become more usable to developers
unlike you and me without losing some Pythonicity?"  Guido seems to
think not (I read him as pessimistic on both grounds: the proposed
syntax is neither as useful nor as Pythonic as Tav thinks it is).