[Python-Dev] anonymous blocks
greg.ewing at canterbury.ac.nz
Thu Apr 21 06:01:35 CEST 2005
Shane Holloway (IEEE) wrote:
> class After:
> def readIt(self, filename):
> In my opinion, this is much smoother to read. This particular example
> brings up the question of how arguments like "aFile" get passed and
> named into the block. I anticipate the need for a place to put an
> argument declaration list. ;)
My current thought is that it should look like this:
with_file(filename) as f:
The success of this hinges on how many use cases can
be arranged so that the word 'as' makes sense in that
position. What we need is a corpus of use cases so we
can try out different phrasings on them and see what
looks the best for the most cases.
I also have a thought concerning whether the block
argument to the function should come first or last or
whatever. My solution is that the function should take
exactly *one* argument, which is the block. Any other
arguments are dealt with by currying. In other words,
with_file above would be defined as
f = open(filename)
This would also make implementation much easier. The
parser isn't going to know that it's dealing with anything
other than a normal expression statement until it gets to
the 'as' or ':', by which time going back and radically
re-interpreting a previous function call could be awkward.
This way, the syntax is just
expr ['as' assignment_target] ':' suite
and the expr is evaluated quite normally.
> Another set of question arose for me when Barry started musing over the
> combination of blocks and decorators. What are blocks? Well, obviously
> they are callable. What do they return? The local namespace they
I think the return value of a block should be None.
In constructs like with_file, the block is being used for
its side effect, not to compute a value for consumption
by the block function. I don't see a great need for blocks
to be able to return values.
> How do blocks work with control flow statements like
> "break", "continue", "yield", and "return"? Perhaps
> "break" and "continue" raise exceptions similar to StopIteration in this
Something like that, yes.
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