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