On Thu, Feb 20, 2020 at 12:43 PM Steve Jorgensen email@example.com wrote:
But frankly, it would be a rare case where this would be noticeable. -CHB
Maybe uncommon, but I don't know about rare. Let's say you want to perform list-wise computations, making new lists with results of operations on existing lists (similar to numpy, but maybe trying to do something numpy is unsuitable for)? You would want to pre-allocate the new array to the size of the operand arrays.
Not rate that you’d have a use case, but rate that the performance would be in issue. In past experiments, I’ve found the array re-allocation scheme is remarkably performant.
On the other hand, all the methods suggested in this thread require at least a double allocation— which may not be noticeable in many applications, but it’s also a fairly light lift to make a single constructer for a pre-allocated array.
And as Stephan pointed out — it would help in some high performance situations.
One thing to keep In mind is that array.array is useful for use from C/Cython, when you don’t want the overhead of numpy.
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/2A2LOY... Code of Conduct: http://python.org/psf/codeofconduct/