Named code blockes

[James_Althoff at i2.com]

Alex Martelli writes:

But why should the same design patterns (I'd call them idioms, but
that's just a nuance) be *BEST* in every language?!

<jim response>
I agree, you don't necessarily need nor want the same design
patterns/idioms in every language.  In this instance, though,
I see a lot of similarities between Python and Smalltalk. Hence,
my desire for making the "collection.do()" design idiom a
bit more natural in Python (I agree with Alex and others
that it is "doable" in current Python, as is).  I don't think
this desire denigrates Python as a language in any way
(I _like_ Python).
</jim response>

...

This seems to me to be very much in the same spirit as other
recent or current threads demanding (what the various respective
posters consider) "perfect" syntax sugar for do-until loops,
assignments within an if's condition, declarations of variables,
and so on, and so forth.

<jim response>
Actually, I think it is somewhat different, mainly because
the seamless way that unnamed code blocks were designed in
Smalltalk actually makes it possible to add virtually any
kind of new control structure without adding ANY syntactic
sugar (all manner of loops, exception handling, collection
iteration, coroutines, whatever).  So you don't see the same
debates about adding cluttering language syntax (as noted by
Alex concerning Python) amongst Smalltalkers (of course, you
see lots of other debates :-)  ).
</jim response>

...


It's just about NEVER enough, apparently, to show -- "you CAN
perfectly well do this RIGHT NOW, with MINISCULE syntax sugar
changes from your heart's desire" -- oh no, it HAS to be JUST
EXACTLY _THAT_ syntax sugar, or the demands will never cease.

<jim response>
Sometimes it is enough.  On the other hand, just because
something "can" be done in a language doesn't make it
natural or graceful ("perfectly well" tends to be subjective).
Of course, not everything needs to be (nor can be) supported
exactly to each user's satisfaction either.
</jim response>

...

One genius clamored for a huge new mechanism that would at
last, in the Plenitude of Glory, let him write "let x = y"
versus "set x = y" so he'd get ``declarations'' -- and then,
when somebody showed him how easily he could set things up
so as to write "let.x = y" and "set.x = y", he claimed his
coworkers would kill him if he programmed that way.  Well
isn't that obvious, that being able to have a SPACE there
instead of a PERIOD is the be-all, end-all of programming?!
Isn't it _absolutely_ obvious that placing a period there
will lead to justified homicide...?

<jim response>
(In defense of the "genius" mentioned above, just because
one does not agree with another's opinion does not warrant
rudeness in one's posts.)

Having used the "collection.do()" (more generally,
the "seamlessly integrated" unnamed code block) idiom
extensively in Smalltalk, I very much appreciate its power
and flexibility.  And if there were a way to do it in Python
(in the same seamless fashion -- I agree, again, that it
"can be done", as is) I think it would be great.
I doubt that will happen. (I think it is a tough design
challenge aside from the issue of popularity).
And that's ok.

Obviously Alex (and I'm sure others) feels very passionately
that unnamed blocks aren't so good for Python and that
using current mechanisms including named blocks (via
nested function defs) are just fine.  And that's ok too.
</jim response>