On 8 March 2013 18:23, Jason Orendorff <[email protected]> wrote: > On Thu, Mar 7, 2013 at 1:05 PM, Andreas Rossberg <[email protected]> > wrote: >> >> On 7 March 2013 18:30, Allen Wirfs-Brock <[email protected]> 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 work. 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. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
