[issue32895] Make general function sum() use Numpy's sum when obviously possible

Change by Raymond Hettinger : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Pytho

[issue32895] Make general function sum() use Numpy's sum when obviously possible

Serhiy Storchaka added the comment: I concur with Raymond. NumPy is a third-party library, Python builtins can't depend on it. This could be solved by introducing a special protocol, but this isn't free. It adds a burden on writing and maintaining code and tests, and adds a runtime overhead

[issue32895] Make general function sum() use Numpy's sum when obviously possible

Raymond Hettinger added the comment: > I think many programmers aren't aware of that, so all in all > it can improve the performance of a lot of existing code. We could create a __sum__ dunder method to allow classes to override the normal behavior of sum, but that isn't worth it because the

[issue32895] Make general function sum() use Numpy's sum when obviously possible

Change by ppperry : -- type: performance -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue32895] Make general function sum() use Numpy's sum when obviously possible

Change by ppperry : -- type: enhancement -> performance ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue32895] Make general function sum() use Numpy's sum when obviously possible

Change by ppperry : -- components: +Library (Lib) -2to3 (2.x to 3.x conversion tool) ___ Python tracker ___ ___ Python-bugs-list mail

[issue32895] Make general function sum() use Numpy's sum when obviously possible

New submission from Uri Elias : True at least to PY2.7 and 3.5 - given x is a numpy array, say np.random.rand(int(1e6)), then sum(x) is much slower (for 1e6 elements - 2 orders of magnitude) than x.sum(). Now, while this is understandable behaviour, I wander how hard it is to add a condition