> Just to make sure I understand the desired semantics, is this Python > implementation of sum() accurate: We're no longer aiming for this, but let me point out the fatal flaw in this approach: > def sum(l): > '''sum(sequence) -> value > > Returns the sum of a non-empty sequence of numbers (or other objects > that can be added to each other, such as strings, lists, tuples...).''' > > it = iter(l) > next = it.next > > try: > first = next() > except StopIteration: > raise ValueError, 'sum() arg is an empty sequence' > > # Special-case sequences of strings, for speed > if isinstance(first, str): > try: > return first + ''.join(it) > except: > pass Suppose the iterator was iter(["a", "b", "c", 1, 2, 3]). The "a" is held in the variable 'first'. The "".join() code consumes "b", "c" and 1, and then raises an exception. At this point, there's no way to recover the values swallowed by "".join(), so there's no way to continue. But letting the exception raised by "".join() propagate isn't right either: suppose that instead of [1, 2, 3] the sequence ended with some instances of a class that knows how to add itself to a string: the optimization attempt would cause an error to be thrown that wouldn't have been thrown without the optimization, a big no-no for optimizations. > try: > while 1: > first += next() > > except StopIteration: > return first > > The speed optimization for string sequences is slightly different, but > exposes the same fast-path for the vast majority of likely inputs. Of course, it might have been okay to only invoke "".join() if the argument was a *list* of strings. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4