[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