At 08:13 PM 1/15/05 -0500, James Y Knight wrote:
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.
Uh oh. I just used "view" to describe an iterator as a view on an iterable, as distinct from an adapter that adapts a sequence so that it's iterable. :)
I.e., using "view" in the MVC sense where a given Model might have multiple independent Views.
We really need to clean up our terminology somehow, and I may need to rewrite some parts of my PEP-in-progress. I had been using the term "volatile adapter" for what I'd written so far, but by the time I got to the part where I had to explain how to actually *make* volatile adapters, I realized that I was right before: they aren't adapters just because PEP 246 'adapt()' can be used to create them. They're just something *else* that's convenient to create with 'adapt()' besides adapters. Calling them even "volatile adapters" just confuses them with "real" adapters.
On the *other* hand, maybe we should just call GoF adapters "extenders" (since they extend the base object with a new interface or extended functionality, but aren't really separate objects) and these other things like iterators and views should be called "accessories", which implies you have lots of them and although they "accessorize" an object, they are themselves individual objects. (Whereas an extender becomes conceptually "part of" the thing it extends.)
It's then also clearer that it makes no sense to have a type declaration ever cause you to end up with a new accessory, as opposed to an extender that's at least figuratively always there.
What do y'all think? Is that a better way to distinguish kinds of "adapters"? (I.e. extenders versus accessories) Or does somebody have better words we can use?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
