generator slides review

[andrea crotti]

2014-02-02 Terry Reedy <tjreedy at udel.edu>:
> 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]:
    print(el)

can work, assuming defining an object list-like that just implements
__getitem__.
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