On Tue, 22 Jan 2008 23:33:00 -0800, George Sakkis wrote: > As I mentioned already, I consider the seeking of the most efficient > solution a legitimate question, regardless of whether a "dumb" solution > is fast enough for an application. Call it a "don't be sloppy" principle > if you wish.
Sure, by why do you limit "efficient" and "don't be sloppy" to mean "write the fastest executing code you can, regardless of every other trade-off"? Because there are trade-offs: * execution time * compilation time * memory use at run-time * size of source code on disk * size of compiled code on disk * ease of writing it in the first place * ease of maintenance * correctness * fragility in the face of malformed data * readability and ease of comprehension * elegance (however you judge that!) * making sure the usage of various resources never exceed some set of upper bounds etc. Some of these are relatively unimportant (e.g. the size of the source code), but others are extremely important and far too often ignored (e.g. readability and even correctness). In fact, "fastest" isn't even a meaningful attribute. Does it mean: * the worst-case is fastest * the best-case is fastest * the average-case is fastest * fastest on typical data * all of the above etc. What counts as "typical" data? How do you average all the cases? Asking "what's the fastest" without considering these issues is a good sign that the person asking is being sloppy, something you should be against. > It's the same reason I always use xrange() instead of > range() for a loop, although in practice the difference is rarely > measurable. Well, that's (now) a no-brainer. Once upon a time, range() used to be faster for small enough lists, and whatever difference there is in readability is insignificant except for utter newbies, so there's no real trade-off to make unless you care about the extra "x". But... do you write list.__len__() instead of len(list) to save a few nanoseconds? If you do, you're guilty of pessimization instead of optimization: for built-in lists, len() is actually faster, by a lot. It's only an optimization -- and a significant one -- for custom classes. So, do you write this: if isinstance(alist, list): value = len(alist) # optimize for lists else: value = alist.__len__() # optimize for classes every time you want the length of an arbitrary sequence? If you did, you'd be pessimizing again. That code runs nearly twice as slowly as just calling the built-in len(). Optimizing the parts doesn't mean you have optimized the whole. -- Steven -- http://mail.python.org/mailman/listinfo/python-list