Reply to thread

Message: [QUOTE="Bruno Desthuilliers, post: 1929717"] [URL]http://docs.python.org/lib/module-tempfile.html[/URL] BTW, note that the most common naming convention in Python is all_lower_with_underscore (except for ClasseName). another way : command = 'echo "%s" | lynx -dump -stdin -force_html' % html Note that stdout is usually meant for normal program outputs (so one can pipe programs). Error reporting and verbosities should go to stderr I'm afraid you didn't get the point of exception handling - it's meant to free function results from error code. Your above code totally defeats this - as is obvious when reading the calling code. do_something_useful_here() may I suggest a rewrite : try: redirect = urllib2.urlopen(url).geturl() except urllib2.HTTPError, e: if e.code == 404: print 'NOT FOUND:', url if ignoreNotFound: print '\tWILL NO LONGER ATTEMPT TO DOWNLOAD\n' log(url) else: print "geturl HTTPError %s on url %s" % (e.code, url) raise except urllib2.URLError, e: print "geturl URLError %s on url %s" % (e.reason, url) else: do_something_useful_here() html_title_template = """ <hr> <h2>%(title)s</h2> <h3>%(subtitle)s</h3> """ def html_title(title, subtitle): return html_title_template % dict(title=title, subtitle=subtitle) command = 'wget --continue -0 "%s" "%s"' % (dest, url) for feedTitle, castList in q: double negations are harder to grasp: if len(castList) <= x I'm not sure to get what you're doing here.... Mixing logic and UI is usually a very bad idea IMHO. This will make this function hard to use in a different context (like ie a mod_apache handler, a GUI, etc... You'd better raise some specific exception and let the caller handle it. (snip) yes : using the logging module OMG. optparse is far better than this. (snip) My overall feeling is that in most function, you're mixing too much different concerns. Each function should do *one* thing (and do it well). The most obvious problem here is about mixing application logic and UI. Application logic (what your app is effectively doing) should be as independant as possible of UI concerns. If possible, you should be able to reuse most of the application logic (except for the main() func, which in your case is the command-line UI) as a module in other applications. Now there are time when the application code needs to notify the UI. The good news is that Python makes it easy to makes this generic, using callback functions or objects provided by the UI and called when appropriate by the application logic. The key here is to come up with a clear, well-defined interface between logic code and UI code. A last point : avoid globals whenever possible. Either pass values as arguments to functions or use a kind of config object if there are too much configuration stuff. My 2 cents [/QUOTE]

Verification