At 06:56 PM 1/14/05 +0100, Just van Rossum wrote:

Phillip J. Eby wrote:

...

For example, if there were a weak reference dictionary mapping objects to their (stateful) adapters, then adapt() could always return the same adapter instance for a given source object, thus guaranteeing a single state.

Wouldn't that tie the lifetime of the adapter object to that of the source object?

Well, you also need to keep the object alive if the adapter is still hanging around. I'll get to implementation details and alternatives in the PEP.

Possibly naive question: is using adaptation to go from iterable to iterator abuse? That would be a clear example of per-adapter state.

I don't know if it's abuse per se, but I do know that speciifying whether a routine takes an iterable or can accept an iterator is often something important to point out, and it's a requirement that back-propagates through code, forcing explicit management of the iterator's state. So, if you were going to do some kind of adaptation with iterators, it would be much more useful IMO to adapt the *other* way, to turn an iterator into a reiterable. Coincidentally, a reiterable would create per-object state. :) In other words, if you *did* consider iterators to be adaptation, it seems to me an example of wanting to be explicit about when the adapter gets created, if its state is per-adapter. And the reverse scenario (iterator->reiterable) is an example of adaptation where shared state could solve a problem for you if it's done implicitly. (E.g. by declaring that you take a reiterable, but allowing people to pass in iterators.)