On 2015-09-30 23:24, Andrew Barnert via Python-ideas wrote:
There are things that are iterables, that are not non-iterator iterables, but the reverse is not true. It's a name for a strict subset. Which means it's more specific.
As for a new requirement: an iterable is a non-iterator iterable if its __iter__ method does not return self.
Not sure I followed all the discussion of these terms, but is your main reason for wanting this term to describe the behavior that non-iterator iterables can be "restarted" (and are so restarted if reused in a different context)? Personally I prefer to take a duck-typing view and focus on what operations you can or can't do on these various things. Whether you call it a view or a virtual indexer or whatever is, to me, less important than what you can do with the object. I agree there are a number of relevant subcategories of objects here, some of which we have a name for and some that we don't. But I think it gets easier if we move from generic nouns like "view" to specific adjectives describing the behaviors the object support. Something like "re-entrant iterable" (meaning if you use it in two for loops right after each other you get the whole thing both times) would focus on that aspect of the behavior. Something like "random-accessible" or "sliceable" if we want to talk about iterables where we can "jump ahead" or slice if needed. It's an interesting idea to think about what kinds of operations (map, filter, etc.) could return iterables supporting what other kinds of operations. That is, can we make sure the result of map/filter can be sliced/indexed/reentered if the source can. To me the interesting question is which of these actual behaviors can usefully and non-mind-bendingly be preserved through map/filter/etc. manipulations. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown