itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
Jack Diederich
jack at performancedrivers.com
Mon Mar 28 12:56:48 EST 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