Yes, I cede that explicit indexing is faster by quite a bit. There is a somewhat philosophical decision for why I avoided that. I prefer to try to present python with as big of a picture of what I want as possiable. update tells python what I want to do, whereas the for-loop describes how to. It happens that the for-loop is faster, for python 2.4, but there where two thougths that I had going on:
1. Describe what, rather than how. Perhaps one day update will as efficent as slicing is today (another area that screams for for-loops.) The difference between the indexing for-loop and update is that the actual work of searching for a key, reassigning, searching for the next is done in the python vm for the loop, and c for the update. I would expect the later to be faster, and am actually flipping to that page of source to better understand how and why I embarrased myself today. 2. Generator's, interpolations for both lists and generators and mechanisms by which to work on a stream of data are actively researched and improving rapidly. For these two reasons, part of me is afraid to use the hash table index lookup, its sort of a premature optimization and I don't want my code to smell clunky in the future. Also, the testing begs of the question of if this is a valid test data set, if it is, then its obviously small enough to not bother benchmarking, and if it isn't, then again, there is no point to benchmarking on it. :-) In hindsight, along with whatever application I found myself deliberating these differences, I'd include some documentation and a test script that could be run in the future to confirm that the performance benefits of the decision still held. As for the asthetic qualties, well, you are right. Its ugly. Personally, I don't have a problem reading nested interpolations, but most people dislike them for the same reason they dislike lisp. Parenthesis are surprisingly hard to count. -- http://mail.python.org/mailman/listinfo/python-list
