Perhaps drawing a distinction between containers (or maybe "collections"?), and non-container iterables is appropriate?  I would define containers as objects that can be iterated over multiple times and for which iteration does not instantiate new objects.  By this definition generators would not be considered containers (but views would), and for practicality it may be worth also having an ABC for containers-and-generators (no idea what to name it).  This would result in the following hierarchy:

- strings, bytes, etc.
- containers-and-generators
- - containers
- - - tuple, list, set, dict views, etc.
- - generators

I don't think there needs to be different operations defined for the different ABCs.  They're all just iterables with different iteration semantics.


On Tue, May 27, 2008 at 3:54 PM, Raymond Hettinger <> wrote:
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.

Well said.

Guido had at least a start in Searchable, back when ABC
were still in the sandbox:

Have to disagree here.  An object cannot know in general
whether a flattener wants to split it or not.  That is an application
dependent decision.  A better answer is be able to tell the
flattener what should be considered atomic in a given circumstance.