This seems sensible to me. I remember Guido vetoing allowing random.choice() to accept a set, and for the same reason - it encourages inefficient code. Rob Cliffe On 16/06/2021 15:50, Oliver Margetts wrote:
Hi all, I came across the following performance issue with the sum function while summing lists: https://bugs.python.org/issue18305 https://bugs.python.org/issue18305 It's been discussed previously in this list and other issues.
The rationale in that ticket makes the case that performance won't be fixed because sum() should not be treated as a generic way to concatenate sequences (and there is documentation saying this).
Having non-linear complexity is not a suitable way to discourage this behaviour though. Non-linearity is hard to detect in testing and development, so is more likely to lead to performance bugs in libraries and production, than to discourage use from the outset. Moreover, it is confusing to end users to have a feature while discouraging its use through a somewhat passive-aggressive runtime. New users, and experienced users who do not pour through the documentation will use sum because it supports this API, and one would assume that's intentional.
On the other hand, the behaviour for strings is a far superior user-experience. When attempting to use sum() on strings, users are presented with a TypeError and a handy tip (use "".join(seq) instead). It is clear to users that they are attempting an anti-pattern and how to correct it.
So I propose moving (eventually) to the same system with lists as for strings. Or else removing the performance trip-hazard from the sum function with lists.
Best regards, Oliver
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JHW5LT... Code of Conduct: http://python.org/psf/codeofconduct/