2014-02-02 Terry Reedy <tjre...@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
--
https://mail.python.org/mailman/listinfo/python-list
