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

Jack Diederich jack at performancedrivers.com
Mon Mar 28 19:56:48 CEST 2005


On Mon, Mar 28, 2005 at 10:28:29AM -0700, Steven Bethard wrote:
> Jack Diederich wrote:
> >
> > itertools to iter transition, huh?  I slipped that one in, I mentioned
> > it to Raymond at PyCon and he didn't flinch.  It would be nice not to
> > have to sprinkle 'import itertools as it' in code.  iter could also
> > become a type wrapper instead of a function, so an iter instance could
> > be a wrapper that figures out whether to call .next or __getitem__
> > depending on it's argument.
> > for item in iter(mylist).imap:
> >   print item
> > or
> > for item in iter.imap(mylist):
> >   print item
> 
> Very cool idea.  I think the transition from
>     itertools.XXX(iterable, *args, **kwargs)
> to
>     iter.XXX(iterable, *args, **kwargs)
> ought to be pretty easy.  The transition from here to
>     iter(iterable).XXX(*args, **kwargs)
> seems like it might be more complicated though -- iter would have to 
> return a proxy object instead of the object returned by __iter__[1].  I 
> guess it already does that for objects that support only the __getitem__ 
> protocol though, so maybe it's not so bad...

I only included making iter a type to make it more symmetric with str
being a type.  iter is currently a function, as a practical matter I wouldn't
mind if it doubled as a namespace but that might make others flinch.

> [1] And you'd probably also want to special-case this so that if iter() 
> was called on an object that's already an instance of iter, that the 
> object itself was returned, not a proxy.



More information about the Python-list mailing list