On Thu, Mar 23, 2006, Guido van Rossum wrote: > On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> I understand Ian's view since I know I like to pass around iterators >> for use and that disconnects the iterator from the object that >> generated it and thus makes it impossible to find out possible info on >> the data contained without exhausting the iterator compared to just >> performing data upon the object containing the original the data. > > You shouldn't do that unless you are consciously designing an API that > must be able to work with in(de)finite sequences or other strange > things. The itertools library is an example of such an API because (by > intent) it must work for all iterators. > > Most APIs aren't as constrained and it's fine to require an iterable > instead of an iterator.
The problem is that prior to Python 2.1, there weren't any iterators; moreover, my impression is that the majority of the Python community didn't really "get" iterators until fairly recently. I think part of the objection here is that while Py3K is intended to be a point where we can break backward compatibility, semantic breakage is going to be very hard to track down in this case. I'm not really sure where I stand. I *like* the idea of making d.keys() return an iterator, but my impression is that it's going to be one of the more painful changes. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
