On Jan 15, 2005, at 6:02 PM, Simon Percivall wrote: > On 2005-01-15, at 23.50, Just van Rossum wrote: >> Phillip J. Eby wrote: >> >>>> But it _does_ perform an implicit adaptation, via PyObject_GetIter. >>> >>> First, that's not implicit. Second, it's not adaptation, either. >>> PyObject_GetIter invokes the '__iter__' method of its target -- a >>> method that is part of the *iterable* interface. It has to have >>> something that's *already* iterable; it can't "adapt" a non-iterable >>> into an iterable. >>> >>> Further, if calling a method of an interface that you already have in >>> order to get another object that you don't is adaptation, then what >>> *isn't* adaptation? Is it adaptation when you call 'next()' on an >>> iterator? Are you then "adapting" the iterator to its next yielded >>> value? >> >> That's one (contrived) way of looking at it. Another is that >> >> y = iter(x) >> >> adapts the iterable protocol to the iterator protocol. > > Especially since an iterable can also be an object without an __iter__ > method but with a __getitem__ method. Calling __iter__ might get an > iterator, but calling __getitem__ does not. That seems like adaptation. > No? It's still not clear to me, as this shows, exactly what counts as > what in this game. I think that's wrong. To spell iter() in an adapter/interface world, I'd spell iter(obj) as: adapt(obj, IIterable).iterator() Then, list, tuple, dict objects would specify that they implement IIterable. There is a default adapter from object->IIterable which provides a .iterate() method which creates an iterator that uses __getitem__ on the adaptee. In my opinion, adapters provide a different view of an object. I can see treating list "as a" iterable, but not "as a" iterator. James
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4