Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
Why should ``all()`` special case ``range``? Apart from showing off benchmarks, what's the point? Should ``any()`` also special case it? How about other lazy sequences and computed iterables, such as itertools.count objects, itertools.cycle objects, itertools.repeat objects, etc? How many special cases do we want? Personally, I don't *necessarily* oppose special-casing types, but it breaks the independence of types, and couples the all() function and the range() function. To be worth doing, we should get some practical benefit out of it. It isn't clear what that benefit is. Don't get me wrong, its not like I *want* all(range(1, 10**10)) to be slow. But nor do I want to couple the all() function to the range function and complicate the implementation if there is no corresponding benefit. After all, testing with all() is fundamentally an O(N) worst case operation so anything better than that is a nice surprise. If there were special dunders __all__ and __any__ it would be easy to encapsulate this behaviour inside the range objects themselves, and neither any() nor all() would need to know anything about range objects. ---------- nosy: +steven.daprano _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37131> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
