Python 2.3 has made some impressive leaps forward in its support of timezones and the classes that it makes available to handle them. If you are doing anything that uses timezones even remotely you will save yourself a lot of hassle by not using a version of Python older than 2.3! If for some reason you're stuck with Python < 2.3 (like you run a pathetically old distro like Woody) then watch out for the following.
In Python < 2.3 strptime can cause problems if your format string does not specify a timezone as there is no data for Python to set the DST flag in the returned tuple from, so it is left undefined and is filled with a platform specific value. This causes problems if you then try and convert the parsed date into a timestamp and then an ascii time. Usually you end up with a time that is 1 hour out from what it should be! To fix this problem, you can do two things:
Set the DST field to -1 (unknown) explicitly, which causes other time related functions to handle the date correctly using the current timezone of the machine.
ptime = time.strptime("2004-10-06 10:00:00", "%Y-%m-%d %H:%M:%S")[:8] + (-1,)
This is what Python 2.3 does, implicitly.
If you use the subprocess module to spawn a child in one of your threads and you are using locks, there is a possibility of a deadlock. See the discussion in the python newsgroup. Basically, python internally uses locks during imports, and you can fix it in this instance by moving the "from errno import ENOENT, ENOTDIR" line from the _execvpe function in the subprocess.py module up to the top, so that it doesn't happen after the fork(). This affects python 2.4 at least, not sure if it's fixed in 2.5.
If you want to do thread.start_new_thread() from within an app using pygtk, you need to call gtk.gdk.threads_init() first, otherwise the gtk event loop will screw you up.
One page links to PythonNotes:
lib/main.php:944: Notice: PageInfo: Cannot find action page