Path: csiph.com!usenet.pasdenom.info!gegeweb.org!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <lck5pr$reg$1@ger.gmane.org>
References: <CAF_E5JYWZXkq98ri63BMQst3kpPVhO1K5xQbQ0ZHCuRTYZXvUA@mail.gmail.com> <lck5pr$reg$1@ger.gmane.org>
Date: Sun, 2 Feb 2014 10:40:11 +0000
Subject: Re: generator slides review
From: andrea crotti <andrea.crotti.0@gmail.com>
To: Terry Reedy <tjreedy@udel.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.6301.1391337953.18130.python-list@python.org>
Lines: 79
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:65256

2014-02-02 Terry Reedy <tjreedy@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