HTTPError is part of the urllib2 module, so in order to use it you would need to add "import urllib2" to the top of the program, and use "except urllib2.HTTPError:". But, the more important problem is: are you sure that urllib.urlretrieve actually uses HTTPError to report errors? From reading the documentation, it doesn't look to me like it does - I think it just uses IOError. So the actual fix would probably be to replace "except HTTPError:" with "except IOError:".
Some general comments about the code (none of these are actually errors, just style issues):
If you only want to give one argument to the string % operator (lines 9 and 27), there's no need to create a singleton tuple, you can just pass the argument itself. So, for example, you could change line 9 from
Code: Select all
URL_target = "http://www.questionablecontent.net/comics/%s.png" % (comicnum,)
Code: Select all
URL_target = "http://www.questionablecontent.net/comics/%s.png" % comicnum
, which looks neater (to me at least).
There's no need to escape the single quotes in lines 12 and 27: you only need to do that if you're using single quotes to delimit the string. That's the good thing about Python having two different kinds of quotes - you very rarely need to escape quotes in strings, because you can just use the opposite kind of quote to delimit the string (the exception is if you need to have both single and double quotes in the same string, then you're obviously going to have to escape one of them).
You seem to have a few superfluous commas floating around (the last comma on lines 8, 12, 19, 30). They're not doing any harm, but they look strange - I never realised until now that Python would accept that, so it had me confused for a moment.
edit: I suppose I could contribute a couple of my own "it-doesn't-work!" stories. The first one relates to a program I was writing in C... I can't even remember what the program was now, but I remember what I managed to do while writing it. After I added a new bit of code, the program started crashing with a segfault whenever I ran it. The bit of code I added involved allocating some memory with malloc and then accessing it - I knew that it was easy to screw that kind of thing up, so I started carefully checking the code.
Did I calculate the amount of memory to allocate correctly? Yep.
Did I declare the pointer correctly? Yep.
Did I use the correct pointer to access the memory? Yep.
Did I calculate the index to use when accessing the memory correctly? Yep.
Did I free the memory at the correct place? Yep.
Eventually, after checking just about everything else, I figured out what the bug was: I never actually called malloc
. I have no
idea how I managed to do that, or how it took me so long to notice it.
The second story involves another C program that, as part of its output, wrote a large number of floats to a text file using fprintf. The program was, at this point, working perfectly. I decided that a certain bit of the code would be more readable if I changed a couple of the hardcoded integer literals to hex (they were currently written in decimal). I did so, and compiled and ran the program just to check that I hadn't broken anything. It turns out that I had - about half of the floats in the output were now coming out as "0.000000" rather than their correct values. Bear in mind that what I changed couldn't possibly have affected the program's behaviour - the literals still had exactly the same value, just written in a different base - yet it was
affecting the program's behaviour. To cut a long story short, I discovered that the change had somehow triggered a bug in GCC's optimiser - adding -fno-optimize-sibling-calls to the command line restored the correct behaviour. Finding that the bug you've been trying to fix isn't even in your own code is rather annoying.