From: "Guido van Rossum" <guido@python.org>
I'm confused. You & Samuele both sometimes have a rhetorical style that leaves me with no idea of the point you're trying to make.
Please say it outright.
is this the reason why you have not given much feedback on my "rants"?
No, this time your rants were quite clear (at least the second time around).
I need to have time to read all feedback again and think about it.
for example do you agree or disagree that it bad to have scoping rules for some piece of code that depend on some user code somewhere else and that can sometime be quite ambiguous at first glance? Thus the 'class'-like scoping rules case should be syntactically distinguishable from the inline-suite-like case?
I haven't made up my mind on that yet. It appears that the scope of a block in Ruby is quite ambiguous, yet it seems to work there.
What are the scope rules for blocks passed into method calls in Smalltalk?
they are not ambiguous in the sense we are referring here: def f(): x=3 foo: x=4 # new x or old x?
In some Lisps, I believe a function can determine whether its arguments are evaluated before the call (== normal Python semantics) or whether they are somehow (I don't know the details!) passed to the function as parse trees so the function can evaluate them at will. This does not seem to confuse Lisp users. Or does it? I honestly don't know if this is popular or considered a wart.
evolutive ancestors of macros, now they have been substituted with macros, CL and Scheme do not have them.
I do worry that if my thunks are to be maximally useful, they may end up having all variables bound through "cells" (as used for nested scopes) which may give them a reputation of being slow compared to in-line code, which would limit their popularity for control flow statements like synchronized().
yes, that worries me to, it seems at least a likely source of recurring comp.lang.python threads