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:
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 firstname.lastname@example.org wrote:
It isn't really stringiness that matters, it is that you have to terminate even though you still have an iterable container.
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.
Python-3000 mailing list Pythonemail@example.com http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/jgennis%40gmail.com