[issue37131] all(range()...)) is needlessley slow
New submission from Terji : Checking if a range's items are ll truthy can be done y checking if 0 the range contains 0, however currently Python iterates over the range, making the operation slower than needed. >>> rng = range(1, 1_000_000) >>> timeit all(rng) 19.9 ms ± 599 µs per loop If the all function could special case range, this could be like made fast like this: if isinstance(obj, range): if 0 in obj: return False return True -- components: Interpreter Core messages: 344263 nosy: Petersen priority: normal severity: normal status: open title: all(range()...)) is needlessley slow type: performance versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37131] all(range()...)) is needlessley slow
Terji added the comment: >> Why should ``all()`` special case ``range``? Apart from showing off >> benchmarks, what's the point? Mostly to avoid silly mistakes, and the overhead of doing it would be very small, so a very small trade-off. >> Should ``any()`` also special case it? No, ``any()``takes at most two iterations to check truthiness in a ``range()``, so that's wouldn't be needed. >> 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? No, I wouldn't propose that. The argument would be that those are iterators/generators while ``range()`` is special-cased built-in sequence with known properties. -- ___ Python tracker <https://bugs.python.org/issue37131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37131] all(range()...)) is needlessley slow
Terji added the comment: >> 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. This sounds very interesting, and more general. It would be useful for e.g. numpy arrays, where ``all(arr)`` currently is slower than ``arr.all()``. Don't know it there's a reason it wasn't implemented this way originally? -- ___ Python tracker <https://bugs.python.org/issue37131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31564] NewType can subclass NewType
New submission from Terji: It has become possible to create a ``NewType`` from an existing ``NewType``, see https://github.com/python/mypy/pull/3465 and https://github.com/python/peps/pull/271. This is a small update to the documentation as a concequence of the above change. -- assignee: docs@python components: Documentation messages: 302809 nosy: Petersen, docs@python priority: normal severity: normal status: open title: NewType can subclass NewType type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
