[Python-ideas] Integrate some itertools into the Python syntax

[Chris Barker - NOAA Federal]

>>  I think we should think about making the language more
>> iterable-focused.
>
> The *language* has always been iterable-focused.  Python doesn't have
> any counting loops!

Sure.

> range() is a builtin (and a necessary one),

But range used to produce a list.  So for lips were, in the beginning,
about iterating, yes, but iterating through a sequence, not an
arbitrary iterables. I may be wrong here, but I started using Python
in version 1.5, and I'm pretty sure the iterator protocol did not
exist then -- I know for sure I learned about it far later.

And aside from range, there is dict.keys, zip, etc....

> I think the problem is more on the user (and teacher) side.

Well sure - mostly this is about how we present the language, and I at
least am making that switch.

>   That thread never did present a real use case for
> "empty:" with an iterator.

I agree here, actually.

>> for line in the_file[:10]:
>>   ...
>>
>> arrgg! files are not indexable!.
>
> No, they are *enumerable*:
>
>    for i, line in enumerate(the_file):
>        if i >= 10: break
>        ...
>
> I guess your request to make iterators more friendly is a good part of
> why enumerate() got promoted to builtin.

Sure, but you have to admit that the slicing notation is a lot
cleaner. And I don't WANT to enumerate -/ I want


>
>> So maybe there should be some ability to index / slice iterables?
>
> There's no way to index an iterator, except to enumerate it.  Then,
> "to memoize or not to memoize, that is the question."  Slicing makes
> more sense to me, but again the fact that your discarded data may or
> may not be valuable means that you need to make a choice between
> memoizing and not doing so.  Putting that in the API is complexity, or
> perhaps even complication.  If you just want head or tail, then
> takewhile or dropwhile from itertools is your friend.  (I have no
> opinion -- not even -0 -- on whether promoting those functions to
> builtin is a good idea.)
>
>> But aside from that -- just the idea that looking at how to make
>> iterable a more "natural" part of the language is a good thing.
>
> I think it's from Zen and the Art of Motorcycle Maintenance (though
> Pirsig may have been quoting), but I once read the advice: "If you
> want to paint a perfect painting, make yourself perfect and then paint
> naturally."  I think iterators are just "unnatural" to a lot of
> people, and will remain unnatural until people evolve.  Which they may
> not!
>
> Real life "do until done" tasks are careers ("do ... until dead") or
> have timeouts ("do n times: break if done else ...").  In computation
> that would be analogous to scrolling a Twitter feed vs. grabbing a
> pageful.  In the context of this discussion, a feed is something you
> wait for (and maybe timeout and complain to the operator if it blocks
> too long), while you can apply len() to pages.  And you know which is
> which in all applications I've dealt with -- except for design of
> abstract programming language facilities like "for ... in".  The point
> being that "real life" examples don't seem to help people's intuition
> on the Python versions.
>
>
>