Ruby-styled blocks in Python have been something to be a bit anxious
about. After spending even a little time working with Ruby, it’s really
hard to get the idioms that blocks facilitate out of your head. Dealing
with certain types of problems with coroutines just feels right:
File.open("bla.txt") do |file|
file.read()
end
With the equivalent Python being roughly:
file = open('foo.txt')
try:
file.read()
finally:
file.close()
Eewww. What attracted me to Python was its ability to make code read
very closely to its intent as it would be described by a human. Resource
aquisition/release is one of those things that I’d rather not have to
read about when I’m trying to extract the essence of what a piece of
code is doing.
Of course, you can get close in most cases by using normal callable
passing…
def with_open_file(file, block):
try:
block(file)
finally:
file.close()
def do_stuff(file):
file.read()
with_open_file(open('bla.txt'), do_stuff)
… but the Ruby block syntax reads better to these eyes and it seems
I’m not the only one. A few weeks ago, Guido had this to say
about the block style in relation to recent PEP activity:
That was all before I (re-)discovered yield-expressions (in Ruby!),
and mostly in response to the most recent version of PEP 288, with its
problem of accessing the generator instance. I now strongly feel that
g.next(EXPR) and yield-expressions are the way to go.
So I’ve been following the succession of PEPs that have led us to
PEP-342, Coroutines via Enhanced Generators, and
PEP-343, Anonymous Block Redux and Generator
Enahncements, with great interest.
It looks like there’s a decent chance that we’ll be able to stuff like
this in Python 2.5:
@with_template
def opening(filename, mode="r"):
file = open(filename, mode)
try:
yield file
finally:
file.close()
with opening("/etc/passwd") as file:
file.read()
This is accomplished not by adding an implicitly passed block construct
like Ruby’s &block, but by adding a basic message passing protocol for
generators. Generators will have two new methods: send and
throw. The important one here is throw, which tells the generator to
raise an Exception at its suspension point. All of this is hidden
behind the implementation of with_template (sample implementation in
PEP-342).
What I’m interested in understanding more fully is how the PEP proposed
enhancements to generators will work in iterative cases or whether
that’s planned at all. The examples seem targeted toward resource
aquisition/release (which is fine, there’s definitely a strong set of
use cases in that area). But I’m interested in understanding how cases
similar to Ruby’s IO.foreach will be handled:
IO.foreach("testfile") { |line| puts line }
Note that this is different from Python’s…
for line in open('testfile').readlines():
print line
… for a few reasons. First, resource aquisition/release is handled
within IO.foreach where in the preceding Python snippet, it isn’t
really handled at all. Second, IO.foreach reads the file iteratively,
calling the block each time, where as an approach using Python
generators, such as follows…
def lines(filename):
f = open(filename)
try:
line = f.readline()
while line:
yield line
line = f.readline()
finally:
f.close()
for line in lines('foo.txt'):
raise Exception("this doesn't work")
… falls apart because the exception raised in the iterating block is
not automatically signaled back to the generator. There’s no guarantee
that the finally block will execute when the iterating block exits.
I have a feeling there’s some aspect of this that I’m not fully
grasping. Perhaps Phillip (PING) or someone else with a good understanding of
the proposed generator enhancements can stop by and comment; inquiring
minds want to know…