Questions/issues regarding generators

Andreas Rossberg rossberg at
Thu Mar 14 15:48:58 PDT 2013

On 8 March 2013 18:23, Jason Orendorff <jason.orendorff at> wrote:
> On Thu, Mar 7, 2013 at 1:05 PM, Andreas Rossberg <rossberg at>
> wrote:
>> On 7 March 2013 18:30, Allen Wirfs-Brock <allen at> wrote:
>> > Zip's informal contract should state that if iterators are passed as
>> > arguments they need to be distinct objects. If you want to implement it
>> > defensively, you can add a  check for that pre-condition.
>> I have to disagree here. That is just evading the question what the
>> contract for .iterator is. Either it is supposed to create new state
>> or it isn't. It's not a very useful contract to say that it can be
>> both, because then you cannot reliably program against it.
> In Python, the contract definitely says that it can be both. It's the only
> practical choice. For collections, you want new state. But you also want
> things such as generators, database cursors, and file descriptors to be
> iterable:
>     with open(filename, 'r') as f:
>         for line in f:
>             handle_input(line)
> and you definitely don't want new state here, because what would that even
> mean? A read position is kind of inherent to a file descriptor, right?

A generator is an abstraction that is intended to be invokable many
times. Are you saying that there are generators for which you cannot
do that?

All I'm suggesting (in my original proposal) is that iterator creation
is always performed in the .iterator method. For generators that means
that you can create multiple iterators from one generator application,
but that would be no different from what you can do anyway by invoking
the same generator with the same arguments multiple times.

The stratification I suggest reconciles generators with a clean
contractual interpretation of iterables. Among other things, that
allows generators to be used in combination with both abstractions
over iterators as well as abstractions over iterables (which are
different beasts!). Under the current semantics, that does not really

I can see that the suggestion might look like a complication, but I
think it is a fairly minor one, and more importantly, in practice will
almost always be confined to abstractions.


More information about the es-discuss mailing list