flying sheep added the comment: > The *iterable* itself may be reentrant, but the iterator formed > from iter(iterable) is not. So by your previous comment, giving > the iterator form a length is not appropriate.
> With the exception of tee, all the functions in itertools return > iterators. ah, so your gripe is that the itertools functions return iterators, not (possibly) reentrant objects like range(). and changing that would break backwards compatibility, since the documentation says “iterator”, not “iterable” (i.e. people can expect e.g. next(groupby(...))) to work. that’s probably the end of this :( the only thing i can imagine that adds reentrant properties (and an useful len()) to iterators would be an optional function (maybe __uniter__ :D) that returns an iterable whose __iter__ function creates a restarted iterator copy, or an optional function that directly returns such a copy. probably too much to ask for :/ > Since you can't rely on it having a length, you have to program as if > it doesn't. So in practice, I believe this will just add complication. I don’t agree here. If something accepts iterables and expects to sometimes be called on iterators and sometimes on sequences/len()gthy objects, it will already try/catch len(iterable) and do something useful if that succeeds. > The best we ended-up with has having __length_hint__ to indicate size to > list(). Just out of interest, how does my __uniter__ compare? > because it changed their boolean value from always-true it does? is it forbidden to define methods so that int(bool(o)) != len(o)? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24849> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
