itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)

[Steven Bethard]

Ville Vainio wrote:
> A minimal set would not be that offensive, yes. But then we would have
> two places to look for itertools functionality, which may not be
> desirable. 

True, though this is currently necessary with str objects if you want to 
use, say string.maketrans, so it's not without some precedent.  If it's 
necessary to leave anything in itertools, my suggestion would be that 
the documentation for the iter "type" have a clear "see also" link to 
the itertools module.

> One thing that might be worth keeping in mind is that some of
> itertools functionality is going to become obsolete come py3k
> (izip->zip), and some is already (imap). At least such operations
> should not be dumped into the builtin iter.

Yeah, maps and filters are basically obsolete as of generator 
expressions.  The list of itertools functions that don't seem obsolete 
(and won't be made obsolete by Python 3.0):

chain
count
cycle
dropwhile
groupby
islice
repeat
takewhile
tee

As I suggested, I think that chain, islice and tee are tightly coupled 
with iterator objects, providing concatenation, slicing and copying 
operations.  This leaves:

count
cycle
dropwhile
groupby
repeat
takewhile

None of these really have analogs in sequence objects, so I consider 
them less tightly tied to iter.  I'd probahbly say that these are more 
along the lines of alternate constructors, ala dict.fromkeys.  While 
they're certainly useful at times, I'd be happy enough to leave them in 
itertools if that was the general feeling.  Of course I guess I'd be 
happy enough to leave everything in itertools if that was the general 
feeling (or the BDFL pronouncement). ;)

STeVe