Peter Otten wrote: > Carl Banks wrote: > > > def process_values(lst): > > if not lst: > > return > > do_expensive_initialization_step() > > for item in lst: > > do_something_with(item) > > do_expensive_finalization_step() > > > What if you called the function like this: > > > > process_values(x.strip() for x in values_lst) > > > > Oops, now we've just gone through an expensive initialization and > > finalization for nothing (since values_lst was empty). Maybe some > > subtle bugs introduced. If we're lucky, the finalization step will > > throw an exception. > > The good news is that the above has a 99 percent chance that it just works > with iterators/generators -- even though the writer may not have been aware > of them/they didn't exist when the code was written...
There's a litmus test I like to use when justifying something with percentages: I imagine that I'm presenting it to my boss, and ask myself if I still expect to have a job the next day. :-) Yes, I agree with you, it most cases I expect merely unnecessary work. (Which is not the best news; the best news would be an exception right away.) That's why I think this is only a "pretty good" reason to use "if len(lst)>0", not a slam dunk. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
