Why don't generators execute until first yield?

[Martin Sand Christensen]

Hi!

First a bit of context.

Yesterday I spent a lot of time debugging the following method in a
rather slim database abstraction layer we've developed:

,----
| def selectColumn(se lf, table, column, where={}, order_by=[], group_by=[]):
| """Performs a SQL select query returning a single column
|
| The column is returned as a list. An exception is thrown if the
| result is not a single column."""
| query = build_select(ta ble, [column], where, order_by, group_by)
| result = DBResult(self.r awQuery(query))
| if result.colcount != 1:
| raise QueryError("Que ry must return exactly one column", query)
| for row in result.fetchAll RowsAsList():
| yield row[0]
`----

I'd just rewritten the method as a generator rather than returning a
list of results. The following test then failed:

,----
| def testSelectColum nMultipleColumn s(self):
| res = self.fdb.select Column('db3ut1' , ['c1', 'c2'],
| {'c1':(1, 2)}, order_by='c1')
| self.assertRais es(db3.QueryErr or, self.fdb.select Column,
| 'db3ut1', ['c1', 'c2'], {'c1':(1, 2)}, order_by='c1')
`----

I expected this to raise a QueryError due to the result.colcount != 1
constraint being violated (as was the case before), but that isn't the
case. The constraint it not violated until I get the first result from
the generator.

Now to the main point. When a generator function is run, it immediately
returns a generator, and it does not run any code inside the generator.
Not until generator.next( ) is called is any code inside the generator
executed, giving it traditional lazy evaluation semantics. Why don't
generators follow the usual eager evaluation semantics of Python and
immediately execute up until right before the first yield instead?
Giving generators special case semantics for no good reason is a really
bad idea, so I'm very curious if there is a good reason for it being
this way. With the current semantics it means that errors can pop up at
unexpected times rather than the code failing fast.

Martin

[Ian Kelly]

On Wed, May 7, 2008 at 2:29 AM, Martin Sand Christensen <ms*@es.aau.dkw rote:

Now to the main point. When a generator function is run, it immediately
returns a generator, and it does not run any code inside the generator.
Not until generator.next( ) is called is any code inside the generator
executed, giving it traditional lazy evaluation semantics. Why don't
generators follow the usual eager evaluation semantics of Python and
immediately execute up until right before the first yield instead?
Giving generators special case semantics for no good reason is a really
bad idea, so I'm very curious if there is a good reason for it being
this way. With the current semantics it means that errors can pop up at
unexpected times rather than the code failing fast.

Isn't lazy evaluation sort of the whole point of replacing a list with
an iterator? Besides which, running up to the first yield when
instantiated would make the generator's first iteration inconsistent
with the remaining iterations. Consider this somewhat contrived
example:

def printing_iter(s tuff):
for item in stuff:
print item
yield item

Clearly, the idea here is to create a generator that wraps another
iterator and prints each item as it yields it. But using your
suggestion, this would instead print the first item at the time the
generator is created, rather than when the first item is actually
iterated over.

If you really want a generator that behaves the way you describe, I
suggest doing something like this:

def myGenerator(arg s):
immediate_setup _code()

def generator():
for item in actual_generato r_loop():
yield item
return generator()

[Duncan Booth]

Martin Sand Christensen <ms*@es.aau.dkw rote:

Now to the main point. When a generator function is run, it

immediately

returns a generator, and it does not run any code inside the

generator.

Not until generator.next( ) is called is any code inside the generator
executed, giving it traditional lazy evaluation semantics. Why don't
generators follow the usual eager evaluation semantics of Python and
immediately execute up until right before the first yield instead?

You mean you expect the semantics of generators to be that when you
create them, or every time you call next() they run until they hit yield
and then (except for the initial run) return the result that was yielded
the time before? It is easy enough to implement that, but could be a bit
confusing for the user.

>>def greedy(fn):

def greedygenerator (*args, **kw):
def delayed():
it = iter(fn(*args, **kw))
try:
res = it.next()
except StopIteration:
yield None
return
yield None
for value in it:
yield res
res = value
yield res
it = delayed()
it.next()
return it
return greedygenerator

>>@greedy

def mygen(n):
for i in range(n):
print i
yield i

>>x = mygen(3)

0

>>list(x)

1
2
[0, 1, 2]

>>x = mygen(0)
list(x)

[]

>>>

Now try:

for command in getCommandsFrom User():
print "the result of that command was", execute(command )

where getCommandsFrom User is a greedy generator that reads from stdin,
and see why generators don't work that way.

[Martin Sand Christensen]

>>>>"Ian" == Ian Kelly <ia*********@gm ail.comwrites:
IanIsn't lazy evaluation sort of the whole point of replacing a list
Ianwith an iterator? Besides which, running up to the first yield when
Ianinstantiated would make the generator's first iteration
Ianinconsistent with the remaining iterations.

That wasn't my idea, although that may not have come across quite
clearly enough. I wanted the generator to immediately run until right
before the first yield so that the first call to next() would start with
the first yield.

My objection is that generators _by default_ have different semantics
than the rest of the language. Lazy evaluation as a concept is great for
all the benefits it can provide, but, as I've illustrated, strictly lazy
evaluation semantics can be somewhat surprising at times and lead to
problems that are hard to debug if you don't constantly bear the
difference in mind. In this respect, it seems to me that my suggestion
would be an improvement. I'm not any kind of expert on languages,
though, and I may very well be missing a part of the bigger picture that
makes it obvous why things should be as they are.

As for code to slightly change the semantics of generators, that doesn't
really address the issue as I see it: if you're going to apply such code
to your generators, you're probably doing it exactly because you're
aware of the difference in semantics, and you're not going to be
surprised by it. You may still want to change the semantics, but for
reasons that are irrelevant to my point.

Martin

[Martin Sand Christensen]

>>>>"Duncan" == Duncan Booth <du**********@i nvalid.invalidw rites:
[...]
DuncanNow try:
Duncan>
Duncan for command in getCommandsFrom User():
Duncan print "the result of that command was", execute(command )
Duncan>
Duncanwhere getCommandsFrom User is a greedy generator that reads from stdin,
Duncanand see why generators don't work that way.

I don't see a problem unless the generator isn't defined where it's
going to be used. In other similar input bound use cases, such as the
generator iterating over a query result set in my original post, I see
even less of a problem. Maybe I'm simply daft and you need to spell it
out for me. :-)

Martin

[Duncan Booth]

Martin Sand Christensen <ms*@es.aau.dkw rote:

>>>>>"Duncan" == Duncan Booth <du**********@i nvalid.invalidw rites:

[...]
DuncanNow try:
Duncan>
Duncan for command in getCommandsFrom User():
Duncan print "the result of that command was",
execute(command ) Duncan>
Duncanwhere getCommandsFrom User is a greedy generator that reads
from stdin, Duncanand see why generators don't work that way.

I don't see a problem unless the generator isn't defined where it's
going to be used. In other similar input bound use cases, such as the
generator iterating over a query result set in my original post, I see
even less of a problem. Maybe I'm simply daft and you need to spell it
out for me. :-)

It does this:

>>@greedy

def getCommandsFrom User():
while True:
yield raw_input('Comm and?')

>>for cmd in getCommandsFrom User():

print "that was command", cmd
Command?hello
Command?goodbye
that was command hello
Command?wtf
that was command goodbye
Command?

Traceback (most recent call last):
File "<pyshell#5 6>", line 1, in <module>
for cmd in getCommandsFrom User():
File "<pyshell#4 2>", line 11, in delayed
for value in it:
File "<pyshell#5 3>", line 4, in getCommandsFrom User
yield raw_input('Comm and?')
KeyboardInterru pt

[Marco Mariani]

Duncan Booth wrote:

It does this:

>>>@greedy

def getCommandsFrom User():
while True:
yield raw_input('Comm and?')

>>>for cmd in getCommandsFrom User():

print "that was command", cmd
Command?hello
Command?goodbye
that was command hello
Command?wtf
that was command goodbye
Command?

Not here..
In [7]: def getCommandsFrom User():
while True:
yield raw_input('Comm and?')
...:
...:

In [10]: for cmd in getCommandsFrom User(): print "that was command", cmd
....:
Command?hi
that was command hi
Command?there
that was command there
Command?wuwuwuw
that was command wuwuwuw
Command?

[Marco Mariani]

Marco Mariani wrote:

Not here..

Oh, sorry, I obviously didn't see the @greedy decorator amongst all the
quoting levels.

Anyway, the idea doesn't make much sense to me :)

[Duncan Booth]

Marco Mariani <ma***@sferacar ta.comwrote:

Duncan Booth wrote:

>It does this:

>>>>@greedy

def getCommandsFrom User():
while True:
yield raw_input('Comm and?')

>>>>for cmd in getCommandsFrom User():

print "that was command", cmd
Command?hell o
Command?goodby e
that was command hello
Command?wtf
that was command goodbye
Command?

Not here..
In [7]: def getCommandsFrom User():
while True:
yield raw_input('Comm and?')
...:
...:

In [10]: for cmd in getCommandsFrom User(): print "that was command",

cmd

....:
Command?hi
that was command hi
Command?there
that was command there
Command?wuwuwuw
that was command wuwuwuw
Command?

Perhaps if you'd copied all of my code (including the decorator that was
the whole point of it)...

[Marco Mariani]

Duncan Booth wrote:

Perhaps if you'd copied all of my code (including the decorator that was
the whole point of it)...

Sure, I missed the point. Python's symbols become quoting levels and
mess up messages.

Anyway, I would loathe to start execution of a generator before starting
to iterate through it. Especially when generators are passed around.
The current behavior makes perfect sense.