[Python-Dev] Extended Function syntax

[Guido van Rossum]

> > 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?

I hope that if this feature is used in a fairly stylized way, where
usually the function used to lead into the block is a well-known
function, the varying scope rules may not be a problem.

Many users have only a vague notion of the difference between a
syntactic construct and a function (witness repeated suggestions here
and elsewhere that confuse these matters), yet nobody has a problem
with understanding the difference in scope rules between 'def' and
'if' statements, for example.  So I hope that learning that some
functions treat a thunk's scope different than others is no huge
burden.

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.

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().

--Guido van Rossum (home page: http://www.python.org/~guido/)