generator slides review

andrea crotti andrea.crotti.0 at
Sun Feb 2 11:40:11 CET 2014

2014-02-02 Terry Reedy <tjreedy at>:
> On 2/1/2014 9:12 AM, andrea crotti wrote:
> Comments:
> The use is assert in the first slide seem bad in a couple of different
> respects.

Why is it bad? It's probably not necessary but since we ask for a
range it might be good to check if the range is valid.
Maybe I should raise ValueError instead for a better exception?

> The use of 'gen_even' before it is defined.

Well this is because l'm saying that I wish I had something like this,
which I define just after. It might be confusing if it's not defined
but I thought it's nice to say what I would like to do and then
actually define it, what do you think?

> A generator expression evaluates (better than 'yields') to a generator, not
> just an iterator.

Ok thanks fixed

> The definition of 'generator' copies the wrong and confused glossary entry.
> Generator functions return generators, which are iterators with extra
> behavior.

I understood instead that it was the opposite, a generator is a
specialized iterator, so it would be still correct that it returns an
iterator, is that wrong?

> I would leave out For loop(2). The old pseudo-getitem iterator protocol is
> seldom explicitly used any more, in the say you showed.

This was mainly to explain how something like
for el in [1, 2, 3]:

can work, assuming defining an object list-like that just implements
It's not probably how it's implemented for lists but I thought it
could clarify things..

> In 'Even numbers', I have no idea what the complication of next_even() is
> about.
Just because I wanted to find a simple way to get the next even (in
case I pass an odd start number).
I could also do inline but I thought it was more clear..

> 'Lazyness drawbacks' overflow_list is bizarre and useless.  overflow_gen is
> bizarre and buggy. If you are intentionally writing buggy code to make a
> point, label it as such on the slide.

Yes this is intentionally buggy. The thing is that I wanted to show
that sometimes generating things makes it harder to debug, and delays
some errors, which are anyway there but would come up immediately in
case of a list creation.
I could not find a better non artificial example for this, any
suggestion is welcome..

> Iterators just produce values. Generators can consume as well as produce
> values, which is why they can act as both iterators and coroutines.

Well is not more clear to call them in a different way since they do
quite a different job as coroutines or generators? (I see this done
quite often)

Thanks a lot for the great feedback

More information about the Python-list mailing list