[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

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?