On Wed, Mar 3, 2010 at 6:47 AM, Oren Elrad <orenel...@gmail.com> wrote:
> To all that responded, thanks for the prompt response folks, your > criticisms are well taken. Coming from Cland, one is inculcated with > the notion that if the programmer wants to shoot himself in the foot > the language ought not to prevent that (or even should return him a > loaded magnum with the safety off and the hair-trigger pulled). My > apologies for not immediately grokking the cultural difference in > pytown. > > With that said, let me at least offer a token defense of my position. > By way of motivation, I wrote that email after copying/pasting the > following a few times around a project until I wrote it into def > SilentlyDelete() and its cousin SilentlyRmdir() > > """ code involving somefile """ > try: > ........os.remove(somefile) > except: > .......pass # The bloody search indexer has got the file and I > can't delete it. Nothing to be done. > > Certainly the parade of horribles (bad files! corrupt data! syntax > errors!) is a tad melodramatic. Either os.remove() succeeds or it > doesn't and the execution path (in the estimation of this programmer, > at least) is not at all impacted by whether it succeeds or fails. I > know with certainty at compile time what exceptions might be raised > and what the consequences of passing them are and there is no sense > pestering the user or sweating over it. Nor can I see the logic, as > was suggested, in writing "except OSError:" since (seems to me) mere > surplusage -- it neither causes a semantic difference in the way the > program runs nor provides anything useful to the reader. > > What if the user presses Ctrl-C to try to quit the program? Your bare except is catching the KeyboardInterrupts and ignoring them.
-- http://mail.python.org/mailman/listinfo/python-list
