[Python-ideas] Consider making enumerate a sequence if its argument is a sequence
Brendan Barnwell
brenbarn at brenbarn.net
Thu Oct 1 08:44:04 CEST 2015
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
More information about the Python-ideas
mailing list