[Python-Dev] Extended Function syntax

[Samuele Pedroni]

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