Steven D'Aprano wrote: > On the gripping hand, testing for errors before they happen will be slow > if errors are rare:
Hm, might have something to do with why those things intended for handling errors after they happened are called exceptions ;o) > - If your code has side effects (eg changing existing objects, writing to > files, etc), then you might want to test for error conditions first. > Otherwise, you can end up with your data in an inconsistent state. BTW: Has the context management stuff from PEP 343 been considered for implementing transactions? > - Why are you optimizing your code now anyway? Get it working the simplest > way FIRST, then _time_ how long it runs. Then, if and only if it needs to > be faster, should you worry about optimizing. The simplest way will often > be try...except blocks. Basically, I agree with the "make it run, make it right, make it fast" attitude. However, FWIW, I sometimes can't resist optimizing routines that probably don't strictly need it. Not only does the resulting code run faster, but it is usually also shorter and more readable and expressive. Plus, I tend to gain further insight into the problem and tools in the process. YMMV, of course. -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
