[Python-ideas] Intermediate Summary: Fast sum() for non-numbers

[Steven D'Aprano]

On 19/07/13 04:42, David Mertz wrote:
> OK... I have an update to my experiment. I asked by email another friend of
> mine (also middle-aged adult, well-educated, a doctorate in humanities FWIW
> [like me]), this one has had an introductory exposure to programming, and
> in Python specifically, but just one semester-long intro course (the
> wonderful edX MIT Intro to CS, a few months ago).

While we're swapping anecdotes instead of doing proper UI testing *grin* (or perhaps API testing would be a better term), I asked two of my programmers at work what they would do if they had a list of lists and needed to concatenate them into a single list. Both are moderately familiar with Python, although one (call him R) is more familiar with Ruby and Objective-C.

R started with some Ruby code, which was basically the equivalent of reduce, then when I told him that lists supported + for concatenation, said he'd try sum().

At this point, the other programmer (call him M) rolled his eyes and said "You've got to be kidding!". He did not know that lists use + for concatenation, nor that sum() supports lists, and thought that both were terrible ideas and that he'd use a for-loop with extend.

When I hinted that sum() might have performance issues, R was at first incredulous, then once he understood the reason for the performance issues, shrugged and said something along the lines of "Oh well, I'd use sum(), and if it turned out to be too slow for my data, I'd refactor it to use a for-loop. No big deal."

Neither thought that they would gain much if sum() was sped up, M because he wouldn't use it to join lists regardless of speed, and R because he thought it would be unlikely that he'd ever be in a position of needing to join sufficient numbers of lists to really make a difference, but if he was, refactoring was such a trivial exercise that he didn't care one way or another.



-- 
Steven