[Python-Dev] anonymous blocks

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Apr 22 08:19:53 CEST 2005

Brian Sabbey wrote:

> I made an example implementation, and this wasn't an issue.  It took 
> some code to stick the thunk into the argument list, but it was pretty 
> straightforward.

What does your implementation do with something like

   f() + g():

? (A syntax error, I would hope.)

While no doubt it can be done, I still don't like the
idea very much. It seems like a violation of modularity
in the grammar, so to speak. The syntax effectively
allowed for the expression is severely limited by the
fact that a block follows it, which is a kind of backward
effect that violates the predominantly LL-flavour of
the rest of the syntax. There's a backward effect in
the semantics, too -- you can't properly understand what
the otherwise-normal-looking function call is doing
without knowing what comes later.

An analogy has been made with the insertion of "self"
into the arguments of a method. But that is something quite
different. In x.meth(y), the rules are being followed
quite consistently: the result of x.meth is being
called with y (and only y!) as an argument; the insertion
of self happens later.

But here, insertion of the thunk would occur *before* any
call was made at all, with no clue from looking at the
call itself.

> Requiring arguments other than the block to be dealt with by currying 
> can lead to problems.  I won't claim these problems are serious, but 
> they will be annoying.

You have some valid concerns there. You've given me
something to think about.

Here's another idea. Don't write the parameters in the form
of a call at all; instead, do this:

   with_file "foo.txt", "w" as f:

This would have the benefit of making it look more like
a control structure and less like a funny kind of call.

I can see some problems with that, though. Juxtaposing two
expressions doesn't really work, because the result can end up
looking like a function call or indexing operation. I
don't want to put a keyword in between because that would
mess up how it reads. Nor do I want to put some arbitrary
piece of punctuation in there.

The best I can think of right now is

   with_file {"foo.txt", "w"} as f:

> If you google "filetype:rb yield", you can see many the uses of yield in 
> ruby.

I'm sure that use cases can be found, but the pertinent question
is whether a substantial number of those use cases from Ruby fall
into the class of block-uses which aren't covered by other Python

Also, I have a gut feeling that it's a bad idea to try to provide
for this. I think the reason is this: We're trying to create
something that feels like a user-defined control structure with
a suite, and there's currently no concept in Python of a suite
returning a value to be consumed by its containing control
structure. It would be something new, and it would require some
mental gymnastics to understand what it was doing. We already
have "return" and "yield"; this would be a third similar-yet-
different thing.

If it were considered important enough, it could easily be added
later, without disturbing anything. But I think it's best left
out of an initial specification.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

More information about the Python-Dev mailing list