On 11/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > Yes, and at first glance, an IterMixin would be nice. But only at first > glance. > > (1) Things that are already iterators won't implement the entire > newly expanded iteration API. I don't want people to start > mechanically replacing > > for var in seq > > with > > for var in Iter(seq) > > just because they can't remember whether or not it matters.
Short answer: it doesn't. Only if you actually use the new API it matters, e.g. for var in Iter(it1) + Iter(it2): > (2) Some of the functionality in itertools (particularly islice) is > awkward enough that maybe it should be hidden in a library. That way > people are less likely to stumble on it without seeing the > documentation. You can argue the same for a gazillion other python features. There's no way to know that list slicing returns a copy and not a view, or that numpy arrays do the opposite, without reading the docs. > (3) IterMixin would be the only mixin exposed as a builtin -- the > other mixins must be imported. The builtin type factories are > typically the stripped down versions. That problem is solved if we boost up the existing iter() builtin. George _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
