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:
iterables - 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. Jamie On Tue, May 27, 2008 at 3:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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. > > > Raymond > > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/jgennis%40gmail.com >
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
