[Python-iterators] While we're at it...

[Michael Hudson]

"Tim Peters" <tim.one at home.com> writes:

> [Michael Hudson]
> > I'm not sure that's a good idea, but I would like to see an
> > "iterators" module that provided various common iterator
> > manipulations, so you could have eg:
> >
> > def slice(it, lo, hi):
> >     for i in range(lo):
> >         it.next()
> >     for i in range(hi - lo):
> >         yield it.next()
> 
> The number of choices becomes mind-boggling, so prototype this module about
> 6 times first.  

Quite.  It's probably not going to be done by me though (I'm not going
to have decent internet access over the summer, and if 2.2a1 is really
going to be within ... checks ... three weeks (!?) we'd better move
fast on this one).

> Like, who said slice should be a generator?  Maybe they want an
> explicit list.

Well, I was thinking that generally the iterators module would contain
functions that took iterators or iteratable objects as arguments and
return iterators (like the "outer" and "zip" thingies that got chucked
around on python-iterators a couple of months back - and could
probably now be trivially implemented as generators!).

> Maybe they don't want that iterating "it" after calling slice() can
> change the values slice() *later* returns.  Maybe they want slice()
> to return an indexable object too.  Etc.

Well, if we can drum into people that iterators.blah(...) returns an
iterator then these all more or less go away, don't they?

Also turning an iterator into a list is a piece of piss (list(it))
whereas turning a list into an iterator is impossible.  So if there's
no need to materialise the list, one probably shouldn't.

> The 2.2 test_generators.py has a cute class:
> 
> class LazyList:
>     def __init__(self, g):
>         self.sofar = []
>         self.fetch = g.next
> 
>     def __getitem__(self, i):
>         sofar, fetch = self.sofar, self.fetch
>         while i >= len(sofar):
>             sofar.append(fetch())
>         return sofar[i]
> 
>     def clear(self):
>         self.__dict__.clear()

That can go in, then!

I might have time to whip up a strawman proposal (pre-PEP?) in the
next couple of days.

[...] 
> Should probably derive that from UserList instead, to give it a full set of
> list methods.  But then it's not clear what all of them should do.

Well, it should have a few more methods I'd think.

> Since there are so many possibilities, and so little Python
> experience here, I'm very happy to leave the iterator protocol with
> the single method it *must* have.  Anything beyond that is muddy at
> best, so better to leave it alone at first.

I very much agree here!

Cheers,
M.

-- 
  Remember - if all you have is an axe, every problem looks 
  like hours of fun.                                        -- Frossie
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html