[Python-Dev] Extended Function syntax

[Armin Rigo]

Hello Guido,

On Sat, Feb 01, 2003 at 01:29:12PM -0500, Guido van Rossum wrote:
> > >   v = e:
> > >      S
> 
> [Armin]
> > Just to throw more oil on the fire, note that this looks quite a lot like
> > 
> >     for v in e:
> >         S

Sorry, I forgot one step.  I was first thinking about a new 'with' keyword
inspired by an old proposal seen in this list:

   with v in e:
      S

and then realized that the magic necessary for such a 'with' statement (and
thus for "v=e: S") was close to the magic of 'for', in the sense that it
invokes magic methods of 'e' and bind the result to the variable 'v'.  I was
saying that it might be possible to extend the semantics of 'for' to cover
that case too.

Well, in the meantime I've seen Greg's suggestion "def ... as expr:", which I
find much nicer in general.  I am all for it.  The only risk I see is the
temptation to abuse its power for control flow, as it would allow

   def _ as run_synchronized(lock):
     ...

This temptation looks similar to the abuse of the 'class' keyword to use the
metaclass mecanism with concepts unrelated to classes.  In other words, let's
be careful before adding powerful features with associated syntax...

If I may attempt a summary, given all the use cases that have been expressed
in this thread, we could have a need for constructions whose associated code
block is either (1) run immediately or (2) passed unexecuted to some
constructor; and whose variables are (a) in their own namespace or (b) in the
parent namespace.  Currently we have 'class' (1a) and, althought currently a
bit limited in post-processing facilities, 'def' (2a).  I've shown contrived
examples of (2b) using 'for'.  The question is whether we want something
generic enough for all four possible combinations or not, and whether they
should still be statically distinguishable or not.

If they should not, then the 'thunk' approach is fine, given a way to execute
a thunk in its original namespace.  This is a well-known approach in
block-oriented languages, but I agree with Samuele that this can be much
confusing and for some reason I dislike this programming style.  Maybe the
reason is that Python has a pseudo-declarative look & feel that is
incompatible with direct manipulation of control flow.  Such a feature would
make the life impossible for source-processing utilities like code checkers.

But if we want the four cases to be statically distinguisable, then we might
be bound to add various unrelated syntax extensions at several places, all of
which might come with an associated original use case that makes the syntax
look like a hack for radically different uses (like Just's nice
metaclass-based definition of properties).


A bientôt,

Armin.