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