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 -- http://mail.python.org/mailman/listinfo/python-list
